On Wed, Jul 15, 2009 at 5:14 PM, Paul Moore<p.f.mo...@gmail.com> wrote: > 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.
They do offer a solution, but these solution are hard to maintain from a OS packager point of view. In any case I don't see any use case to have a "site-packages" remaining in Python itself. > 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: > [..] > > 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? I totally agree. But I think that the boundary between what Python+stdlib should provide feature-wise and what third party packages provides is still fuzzy and should be made clearer. At some point, third party projects are trying hard to isolate dependencies because they can't do it with the execution environment Python sets by default when you launch a script or an interpreter. site.py loads site-packages and user site-packages at startup basically, and you can use PYTHONPATH / sys.path to add more, but that's partially shared by all apps. To address this issued, a project like zc.buildout will create a local repository of distributions, and will change sys.path on the fly so the local repository is used. virtualenv on its side creates an isolated Python installation for your application, So If the stdlib doesn't provide a standard protocol that goes further than that, people that have this need will continue to use zc.buildout or virtualenv and install many times the same libs on a system. It's perfectly fine from an application developer PoV, but it make site-packages obsoletes and every application installed that way looks like a black box for os packagers. They don't want that. At the end, application developers have to care about the way their applications dependencies are installed, were they should just give the list of those dependencies, and let any package manager project install them. If these matters are not adressed by Python sdtlib, then we should remove the loading of site-packages at Python startup completely, and make it cristal clear that it's not the core/stdlib problem. Otherwise we should think hard about how to let os packagers manage a single repository of Python distributions (and multiple versions) and how application developers could use them from within their applications. This protocol imho could be in the sdtlib even if the implementation is outside, but that's just me. In any case, these issues can be postponed after PEP 376, because that's a another (bigger) part of the puzzle. Regards Tarek _______________________________________________ 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
