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

[Alexis Métaireau]

Hi Srid,

On 12/21/2010 09:41 PM, Sridhar Ratnakumar wrote:
> 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?

Supposing I've understood that part the right way, it's not preventing
to install more than one backend for an ORM. It provides a way to have a
dependency to a project providing an ORM-binding. ORM bindings are
different from ORM backends in my opinion.

Thus, if you do have a better example to propose, I will be very happy
to discuss it here, I find the DB-related example a bit odd too (It's
probably not very likely to have something like that in a real use case).

> 2. What is the expected behavior of 'pip install ORM-bindings'[1]? To
> pick one of the many projects "providing" ORM-bindings?

That's what I have in mind, yes. But until we got a determinist
algorithm, we don't have any way to select the same one on different
installer systems.

That kind of things should be provided by distutils2, but we did not
thought about that until now.

> 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?

"Provides-Release" lists the specific projects provided with this
distribution. One case I can think about is having a distribution
providing two different projects.

A software can have a project for the "core" features and a project for
the "default-plugins". It can then provides the two projects in only one
distribution.

Those can be two virtual projects 'core' and 'defaultplugins', which can
be *provided* by different projects then. This allows to choose between
the possible projects when resolving the dependencies.

setuptools and distribute can be both provided by the same virtual project.

> 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; 

Yep, I understand what you mean. I don't think the Provides-Release is
adapted to deal with those. 'MySQL-python' is *not* a virtual project,
but it is a real one.

In my opinion, the 'Provides-Release' field and virtual project concept
are not to resolve this kind of problems: they are useful to deal with
different *projects* (Distribute and Setuptools) providing the same
features (packaging facilities).

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

Each time, those use cases are related to version distributions, or to
compiler options. If you are dealing with such things, I don't think the
python package index and the current fields (PEP 345) will be useful to you.

I'm not even sure that we need to have some fields to support that at
this level. From what I understand, you have a "psycopg2" version for
each of the postgre distributions. How are we supposed to deal with that
on PyPI ? Arent those dependencies at the OS level rather than the
python level ?

> How would PEP 345's "Provides-Release" help, if at
> all, in describing this scenario?

I'm not sure it will help in this case, unfortunately.

Hope this helps,
Alex