2009/7/15 Tarek Ziadé <ziade.ta...@gmail.com>: > On Wed, Jul 15, 2009 at 12:17 PM, Michael > Foord<fuzzy...@voidspace.org.uk> wrote: >>> Disclaimer: I've only read the short version, so if some of this is >>> covered in the longer explanation, I apologise now. >>> >>> -1. >>> >> >> I agree. People with versioning issues *should* be using virtualenv. >> > > Let's remove site-packages from Python then.
If virtualenv/py2exe/cx_Freeze/py2app don't offer a solution, then maybe you're right. For me, py2exe (and a clean virtual machine if I require an absolutely pristine environment, I guess virtualenv would help here too) does what I need for application packaging. But I'll freely admit that my needs are minimal. Bluntly, as Python stands, import and sys.path do not offer any core support for multiple versions. Custom solutions can be built on top of that - that's what setuptools does. But they are precisely that - custom solutions, and should be supported as such, outside the core (and stdlib). If standard Python support for multi-version imports is required (it's not by me, but I accept that some people want it), then it should be designed in thoughout: - how do I import version 0.7.1 of package foo, rather than 0.7.2? - how do I use foo 0.8 at my interactive prompt, and import bar 0.2 which relies on foo 0.7.1? - what happens if I import foo 2.0 (which requires baz 0.1) and bar 1.5 (which requires baz 0.2)? - what does "import foo" (without a version number) mean? Is it different if it's at the command line or in bar 0.5 (which explicitly declares a dependency on foo 0.7 in its setup.py)? Does the answer to that mean that imports always need to read dependency information? - does your head hurt yet? I could go on... Any PEP dealing with multi versions should address these issues. It's a big area, and I have no interest in it myself, but I do have an interest in avoiding partial solutions which only look at some of the questions that might arise. Look - I really, really don't mind if people use setuptools. Honest. But I do mind if core python gets changed to support little bits of what setuptools does, adding complexity to deal with issues that setuptools handles, but without making it possible to avoid using setuptools. Where's the benefit to anyone then? Paul. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
