PEP 345: real-world examples of "virtual" projects (Provides-Release)
From https://bitbucket.org/ametaireau/python-peps/src/tip/pep-0345.txt """ Provides-Release (multiple use) ::::::::::::::::::::::::::::::: [...] A release may also provide a "virtual" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed. """ 1. I find this to be a strange example. If only one provided project (ORM-bindings) can be installed at any time, what if anyone wants to install more than one DB backends for ORM? 2. What is the expected behavior of 'pip install ORM-bindings'[1]? To pick one of the many projects "providing" ORM-bindings? 3. Did anyone--Alexis and Tarek, in particular--think of real-world use cases for virtual projects (and even "provides" in general) other than the Zope transaction case? If yes, what are they? 4. Personally, I have needs for "virtual" packages from a binary (not source) distribution perspective. For example, "MySQL-python" can be a virtual package "provided by" the binary distributions: mysql5.1-python, mysql5.0-python; similarly, "psycopg2" can be provided by psycopg2-pg8.4 and psycopg2-pg9.0. Or, "modwsgi" can be provided by modwsgi-apache2.2, modwsgi-apache2.4. How would PEP 345's "Provides-Release" help, if at all, in describing this scenario? -srid [1] Or substitute `pip` with any package installer (easy_install, distutils2.install, pypm, enstaller).
participants (3)
-
Alexis Métaireau
-
Marius Gedminas
-
Sridhar Ratnakumar