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).
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
