[Distutils] PEP 345: real-world examples of "virtual" projects (Provides-Release)

[Sridhar Ratnakumar]

 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).