[Catalog-sig] [Distutils] pre-PEP : Synthesis of previous threads, and irc talks + proposals

[Toshio Kuratomi]

zooko wrote:
> On Oct 1, 2008, at 19:10 PM, Tarek Ziadé wrote:
> 
>> I hate the idea of dynamic metadata in fact. I can't express precisely
>> why at that point.
> 
> Me too and me too.
> 
> Perhaps it would help to distinguish between requiring a certain
> functionality and requiring a specific codebase which implements that
> functionality.
> 
> For example: distribution A requires the functionality of ctypes.  That
> part is statically, declaratively always true.
> 
> However, distribution A doesn't necessarily require a *distribution*
> named "ctypes".  If you are running on Python 2.6, then that
> functionality is already present.  If there is a new distribution out
> there named "new_ctypes" which provides the same functionality and the
> same interface but is a completely different code base, then the
> presence of "new_ctypes" satisfies distribution A's requirements.
> 
> The former question is simple, static, and declarative.  The latter
> question isn't.
> 
> In most cases there is only one implementation of a given interface, so
> we make do by equating the interface with the implementation.
> 
> I wonder how Debian and Fedora handle this sort of issue?
> 
With python modules we just require one thing providing the interface.
Let's say that elementtree was merged into python-2.5.  And let's say
that we got python-2.5 as the default python in Fedora 7.  Since we only
have one version of python in any release of Fedora we do something like
this:

  Require: python
  %if 0%{?fedora} < 7
  Require: python-elementtree
  %endif

We are thinking of enhancing what dependency information we Require and
Provide (the problem being... we want to do this automatically.)  If we
get that working, we could do things like:

  Require: python(elementtree)

and in Fedora 6, python-elementtree would have:
  Provide: python(elementtree)

whereas Fedora 7+, the python package would have:
  Provide: python(elementtree)

Note that this information is not as easy to get to as the metadata
provided by eggs so we're still trying to come up with a script that
will generate this data automatically.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20081005/084f1d7d/attachment.pgp>