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