Re: [Distutils] PEP 345: real-world examples of "virtual" projects (Provides-Release)
Hi,
From: Alexis Métaireau <alexis@notmyidea.org> On 12/21/2010 09:41 PM, Sridhar Ratnakumar wrote:
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.
What is the benefit of distributing two projects in a single distribution, compared to the more simpler (traditional) solution of distributing them in separate distributions (and, optionally, making one depend on another; eg: 'core' depend on 'defaultplugins')? Does this benefit justify the cost of introducing a new metadata field?
setuptools and distribute can be both provided by the same virtual project.
Is this the only real-world use of virtual projects? Are there (potential) others?
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; [...] 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.
Ok. -Sridhar ActiveState
Hi, sorry for the delay, I know how this can be irritating sometimes. Le 07/01/2011 23:48, Sridhar a écrit :
What is the benefit of distributing two projects in a single distribution, compared to the more simpler (traditional) solution of distributing them in separate distributions (and, optionally, making one depend on another; eg: 'core' depend on 'defaultplugins')? Does this benefit justify the cost of introducing a new metadata field?
I prefer to distribute things in separated distributions, but it's sometimes simpler to not do that, from the packager POV (because it's only one project to maintain instead of many). I can't say if it's something we really need or not. Maybe the question is to ask to the ones who have introduced and thought about it first (tarek maybe? I'm not sure)
setuptools and distribute can be both provided by the same virtual project.
Is this the only real-world use of virtual projects? Are there (potential) others?
We can have a (fixed) API to deal with something (a database, a parser, etc.), but the internal working is up to the implementation. This means that even the results can be different, but the calls, the API remains the same. One exemple I have in mind is the parsing of .ini files. A virtual project can be "ini-parser", and two implmentations can be a simple ini parser, and a ini parser which supports nested categories. Then, a distributio can depend either on a specific parser, or on the virtual project, depending the needs. If one of those parsers is installed, and a distribution do have a dependency to the virtual dist, then there will be no need to install a specific dist. Maybe can I polish this example and replace the one from the PEP ? Hope this useful, Alex.
participants (2)
-
Alexis Métaireau -
Sridhar