On Fri, Mar 21, 2008 at 9:31 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
The objections to the PEP remain the same as they were then, though: In the requirements, it says "we need", without saying why we need. It then goes on saying "we want" (rephrased) "to duplicate APT and RPM", without saying why we want that, or why that brings us closer to what we need.
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. Nevertheless, the many use cases are related at some level and would benefit from some form of lowest-common-denominator support in the standard library. As an example, IF I wanted to use a library to support multi-version packages or one to ensure I had all the dependencies, I would need to know what versions of things were currently installed. I can't create a library to provided these functionalities and use it downstream of the package creator without some form of standardization to report package versions. (Or at least without running into the assimilation problem that setuptools has). 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. Regards, Alex