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.