Daniel Holth <dholth <at> gmail.com> writes: > Edit the following text:
Okay, here is a possible version: --------------------------------- Provides-Dist (multiple use) Each entry contains a string naming a requirement that is satisfied by installing this distribution. The entry must consist of a name and version. This name of the project identified in the ``Name`` field is implicitly considered as provided, with the version specified in the ``Version`` field. The use of multiple names in this field *must not* be used for bundling distributions together. It is intended for use when projects are forked and merged over time, while providing essentially the same function. Multiple names reflect the evolution of the project over time and not the bringing together of different packages, already distributed elsewhere, in a bundle. Thus, the 'distribute' distribution, a fork of setuptools, could say that it ``Provides-Dist`` a particular version of setuptools, to prevent setuptools from being downloaded and installed when distribute is already installed. If, over time, distribute evolved into a new package called 'distribute2' (for argument's sake), then that could say that it ``Provides-Dist`` a specific version of distribute and a specific version of setuptools. ----------------------------------- Some comments on the above: I'm not entirely comfortable with a Provides-Dist entry which does not specify a version, since it does not allow to you to test that a requirement is actually met. So, I've removed the "optional" qualification from the version. Also: what happens when a requirement is for setuptools (>= X.Y), but the distribute fork hasn't kept pace, and so only supports setuptools at a lower version than X.Y? I take it we're entirely comfortable with installing setuptools X.Y in that case? How would you ensure the right setuptools is always loaded, since presumably both are on sys.path? Regards, Vinay Sajip _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
