Closed njoyce closed 11 years ago
I see your point, and if this project was intended for python developers you'd be right. But it's not - node people mostly use it.
I want only one feature: when a novice user comes in, having a reasonably recent ubuntu/debian installation and types make
, all should work. This won't happen with your patch.
I'd better force people to have dozen of virtualenv
environments around than making bootstrapping more complex for non-python people. Can we make makefile
swallow the venv settings? (ie: is there an equivalent of . venv/bin/activate
)
Additionally, installing this dependencies globally is just crazy: https://github.com/sockjs/sockjs-protocol/blob/master/Makefile#L27-L30
Okay, that makes sense. How about if the environment variable $VIRTUALENV was checked for and if it does not exist force make to run the venv target?
The idea was not to install globally but that you know you're already in a virtualised environment.
Sounds good.
Having thought about this longer, I tend to agree with you - it should be dead simple to get this working.
I have removed the optional virtualenv part and reverted the readme somewhat. What I have done, however is expose the dependencies in a pip friendly format, rather than hidden in the Makefile.
Is the dependency on your fork of WebSocket-for-Python still necessary? The project is still active and recently released 0.2.4. Would switching to that version (assuming it were backward compatible) work?
I really don't know about ws4py. All I know it was very buggy and I preferred to keep the old version that I know works rather than experiment with updated versions. Feel free to try it and report if it's any better.
I always work inside a virtualenv so for sockjs-protocol to require a brand new one to run the tests is too restrictive.
This will be useful when I start using Travis CI to run sockjs-protocol against sockjs-gevent as part of the build.