ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> catalog-sig
catalog-sig
Re: [Catalog-sig] [Distutils] pre-PEP : Synthesis of previous threads, and irc talks + proposals
by Toshio Kuratomi other posts by this author
Oct 5 2008 10:29PM messages near this date
Re: [Catalog-sig] [Distutils] pre-PEP : Synthesis of previous threads, and irc talks + proposals | Re: [Catalog-sig] [Distutils] pre-PEP : Synthesis of previous threads, and irc talks + proposals
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
Thread:
Phillip J. Eby
Chris Withers
Phillip J. Eby
Phillip J. Eby
Ziade Tarek
Zooko
Toshio Kuratomi
Phillip J. Eby
Phillip J. Eby
Ziade Tarek
Ian Bicking
Gael Varoquaux
Ziade Tarek

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved