[Python-Dev] Accept just PEP-0426

[Toshio Kuratomi]

On Mon, Nov 19, 2012 at 07:49:41PM -0500, Donald Stufft wrote:
> Other languages seem to get along fine without it. Even the OS
> managers which have it don't allow it to be used to masquerade
> as another project, only to make generic virtual packages (e.g. "email").
> 
I'm not sure this assertion about OS package managers is correct.  I've only
just read:
http://www.python.org/dev/peps/pep-0426/#provides-dist-multiple-use

but the rough rpm analogue seems to be the Provides: tag.

Provides is given a string which is parsed into a name or a name and version
like this:

Provides: python
Provides: python = 3.1.0

rpm has no way at package build time to tell that a particular name given in
a provides in one package is the actual name of another package.

At installtime, rpm keeps package names and provides names separately but in
dependency comparisons either one can be used to satisfy a requirement.
What that means is that when asking about information on a package with name
"python", you'll get information about the python package with that name and
not about anything else that Provides: "python".  But if you are installing
something that has a requirement on "python" either the package with the
name python or any package that Provides: python can satisfy the requirement.

Package managers with builtin dep solvers can be built on top of rpm.  The
one that I am familiar with is yum.  Since yum is downloading the packages
that are being fed into rpm, yum could choose to prefer the package name
instead of things in Provides when it downloads.  It doesn't, though.  Just
like the underlying rpm, it treats package names and names specificed
through Provides: as equivalent.

-Toshio

> On Monday, November 19, 2012 at 7:43 PM, Daniel Holth wrote:
> 
>     Does it really have baggage? I think it is necessary, although it doesn't
>     do favors to the implementer (and has never been implemented). How else is
>     anyone supposed to fork or merge projects?
> 
>     Daniel Holth
> 
>     On Nov 19, 2012, at 7:37 PM, PJ Eby <pje at telecommunity.com> wrote:
> 
> 
>         On Mon, Nov 19, 2012 at 6:53 PM, Daniel Holth <dholth at gmail.com> wrote:
> 
>             I think this PEP is a significant improvement from its predecessor.
>             It represents features like extras (provides-extra) and build
>             requirements (setup-requires-dist) that are in use in the Python
>             community but cannot be represented in older versions of the
>             format, it finally specifies a UTF-8 encoding, removes RFC 822,
>             provides an extension mechanism, and allows the description to be
>             placed in the document payload.
> 
> 
>         Can we maybe kill Provides-Dist and its associated baggage first,
>         though?
> 
> 
>     _______________________________________________
>     Python-Dev mailing list
>     Python-Dev at python.org
>     http://mail.python.org/mailman/listinfo/python-dev
>     Unsubscribe: http://mail.python.org/mailman/options/python-dev/
>     donald.stufft%40gmail.com
> 
> 

> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/a.badger%40gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121119/d7bbc53a/attachment.pgp>