On Wed, Dec 23, 2009 at 14:04 +0100, [email protected] wrote: > holger krekel <[email protected]> writes: > > > > > Just had a chat on #distutils with Tarek - we are not sure it's generally > > useful. After all, the general solution for the need for different > > interpreter contexts is to use virtualenv or PEP370 and most installed > > But your solution does not work for virtualenv (when using the same > version of python).
why not? py.test$VER is installed additionally - what would break? (btw, i am looking around gentoo currently, seems they have something to do py.test-3.1, i.e. use a dash, and as easy_install is using a dash as well so i consider also going for that for uniformity). > > scripts have no need for the version-differentiations (easy_install/pip > > and py.test are exceptions because they want to run in whatever > > global or local context, that's part of their purpose). > > > > pip is no exception, just like easy_install and py.test are no > exceptions. and just like py.which, which is no exception (hint: you'll > probably also want to version that one) Hum, right. 'py.which' makes sense to be available per-interpreter as well. (For other's information: "py.which pkgname" tells where a package is imported from). > I use a pip script installed in ~/bin for different virtualenvs. there > is no need to install the same pip version in different virtualenvs, nor > is there a need to version the pip binary. This works for me cause it > chooses the right python interpreter for me when I run it (i.e. I use > "#! /usr/bin/env python" as a shebang). is there a windows equivalent for this? > scons also uses an install scheme, where the scons script contains the > above shebang and works with whatever python is first on PATH. is scons a single-file? Otherwise it needs to import its package and that must be installed for all such pythons or do you use PYTHONPATH for that? > btw. I've also ran py.test with the *wrong* python interpreter multiple > times. versioning the py.test script would not have helped me a single > time. ok. for me and judging from the feedback also for others it would help. > spurred by this discussion I'm now creating a single file py.test script > which includes the whole py library. This would allow people to drop > that script in ~/bin/ and run it with any virtualenv they are using > *without* installing the py lib first (well strictly speaking it is > installed as a single file). What do you think about that? Interesting. Curious how you approach this. Encoding a zip-file into the single-file? There is the matter of startup-time because there would be no sensible '.pyc' files. But OTOH distributing a single script is useful enough to make up for this penalty. If you try this and have issues feel free to drop by #pylib on freenode or mail here for help. Puh, it seems there are tons of different combinations of how python tools are packaged, distributed and used. Let me ask the other way around: would additional "py.test-$VER" targets present a problem for you? Eventually with i'd like to go for the "-i 2.4,2.5,2.6,jython,pypy-c" idea mentioned before. best, holger _______________________________________________ py-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/py-dev
