On 22/03/2008, Alexander Michael <[EMAIL PROTECTED]> wrote: > > IOW, the PEP is lacking a rationale. > > It seems to me that this discussion is being undermined by not > acknowledging the many use cases up front. There is no rationale > because there are too many tacit rationales.
Absolutely! It feels like people are trying to design a solution without having written up the problem spec. Maybe that's because there are too many problems for a single solution to work in all cases? > My personal use case is for multi-version packages. I deploy many > small scripts (not applications) that use an evolving set of base > libraries. I don't want the older scripts to hold me back from pushing > forward with the base libraries, so I peg the scripts to their > respective major versions as I release them. My personal use case is for a Windows system with a number of adhoc scripts, which may depend on 3rd party libraries, and a number of "applications" (3rd party or otherwise) written in Python. I want the applications to use a bundled Python and library, via py2exe. There should be no dependency on the "system" Python. Adhoc scripts can depend on libraries installed into the system Python, but generally there will be a "base" set of libraries that I will always have installed and which can be assumed to be present (pywin32, cx_Oracle, py2exe, ...). Scripts can use these without restriction but should be prepared to work with whatever version is present. It should (almost) never be a problem to a script if a library gets upgraded. Additional libraries may be installed in the system Python, for one-off jobs, or for testing and development. I will install and remove these at will, and nothing critical should break ifn I do. There is generally no other Python present on the system. On my development machine, I may have alternative versions installed, and I may have trunk checkouts with a python.exe built, but these will never be used for anything other than specific development tasks, and are treated as "throw-away". It's very rare that any 3rd party library will be installed in these, and special handling when it does happen is entirely acceptable. For the system Python, I need: - a single way to list what's installed (including version) - a single way to uninstall items as needed - a way (or more than one) to install 3rd party software *which ties into the above* The key maintenance task I do on the system Python is to list everything installed, uninstall them all, upgrade the system Python, then reinstall the ones I had installed previously. (Don't bother telling me there are other ways I could do this - that's not the point here, this is how I actually work). The reason setuptools/easy_install breaks this is because it fails the "single way" test. I have to use bdist_wininst for some packages, so setuptools *has* to integrate with that. Also, setuptools doesn't have the list and uninstall features. So that's my problem/requirements. Anything that solves this gets +1 from me. Anything else gets -1 or at best -0. Anything that adds extra features while not solving my problem gets a strong -1, as the extra features will encourage take-up of that solution, exacerbating my current problem. 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