Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Daniel Holth]

There you go.


Obsoleted-By (optional)
:::

Indicates that this project is no longer being developed.  The named
project provides a substitute or replacement.

A version declaration may be supplied and must follow the rules described
in `Version Specifiers`_.

The most common use of this field will be in case a project name changes.

Examples::

Name: BadName
Obsoleted-By: AcceptableName

Obsoleted-By: AcceptableName (>=4.0.0)
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Paul Moore]

On 10 December 2012 16:35, Toshio Kuratomi  wrote:
> I have no problems with Obsoletes, Conflicts, Requires, and Provides types
> of fields are marked informational.  In fact, there are many cases where
> packages are overzealous in their use of Requires right now that cause
> distributions to patch the dependency information in the package metadata.

Given the endless debate on these fields, and the fact that it pretty
much all seems to be about what happens when tools enforce them, I'm
+1 on this. Particularly as these fields were not the focus of this
change to the spec in any case.

Paul.
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Toshio Kuratomi]

On Fri, Dec 7, 2012 at 10:46 PM, PJ Eby  wrote:

>
> In any case, as I said before, I don't have an issue with the fields
> all being declared as being for informational purposes only.  My issue
> is only with recommendations for automated tool behavior that permit
> one project's author to exercise authority over another project's
> installation.


Skipping over a lot of other replies between you and I because I think that
we disagree on a lot but that's all moot if we agree here.

I have no problems with Obsoletes, Conflicts, Requires, and Provides types
of fields are marked informational.  In fact, there are many cases where
packages are overzealous in their use of Requires right now that cause
distributions to patch the dependency information in the package metadata.

-Toshio
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

On Mon, Dec 10, 2012 at 3:27 AM, Stephen J. Turnbull  wrote:
> PJ Eby writes:
>
>  > By "clear", I mean "free of prior assumptions".
>
> Ah, well, I guess I've just run into a personal limitation.  I can't
> imagine thinking that is "free of prior assumptions".  Not my
> own, and not by others, either.

I suppose I should have said, "free of *known* prior assumptions",
since the trick to suspending assumptions is to find the ones you
*have*.

The deeper assumptions, alas, can usually only be found by clashing
opinions with others...  then stepping back and going, "wait...  what
does he/she believe that's *different* from what I believe, that
allows them to have that differing opinion?"

And then that's how you find out what it is that *you're* assuming,
that you didn't know you were assuming.  ;-)  (Not to mention what the
other person is.)


>  > Put together, the phrase "clear thinking on concrete use cases" means
>  > (at least to me), "dropping all preconceptions of the existing design
>  > and starting over from square one, to ask how best the problem may be
>  > solved, using specific examples as a guide rather than using
>  > generalities."
>
> Sure, but ISTM that's the opposite of what you've actually been doing,
> at least in terms of contributing to my understanding.  One obstacle
> to discussion you have contributed to overcoming in my thinking is the
> big generality that the packager (ie, the person writing the metadata)
> is in a position to recommend "good behavior" to the installation
> tool, vs. being in a position to point out "relevant considerations"
> for users and tools installing the packager's product.

Right, but I started from a concrete scenario I wanted to avoid, which
led me to question the assumption that those fields were actually
useful.  As soon as I began questioning *that* assumption and asking
for use cases (2 years ago, in the last PEP 345 revision discussion),
it became apparent to me that there was something seriously wrong with
the conflicts and obsoletes fields, as they had almost no real utility
as they were defined and understood at that point.

> Until that generality is formulated and expressed, it's very difficult
> to see why the examples and particular solutions to use cases that
> various proponents have described fail to address some real problems.

Unfortunately, it's a chicken-and-egg problem: until you know what
assumptions are being made, you can't formulate them.  It's an
iterative process of exposing assumptions, until you succeed in
actually communicating.  ;-)

Heck, even something as simple as my assumptions about what "clear
thinking" meant and what I was trying to say has taken some back and
forth to clarify.  ;-)

> It was difficult for me to see, at first, what distinction was
> actually being made.
>
> Specifically, I thought that the question about "Obsoletes" vs.
> "Obsoleted-By" was about which package should be considered
> authoritative about obsolescence.  That is a reasonable distinction
> for that particular discussion, but there is a deeper, and general,
> principle behind that.  Namely, "metadata is descriptive, not
> prescriptive."

Actually, the principle I was clinging to for *both* fields was not
giving project authors authority over other people's projects.  It's
fine for metadata to be prescriptive (e.g. requirements), it's just
that it should be prescriptive *only* for that project in isolation.
(In the broader sense, it also applies to the distro situation: the
project author doesn't really have authority over the distro, either,
so it can only be a suggestion there, as well.)
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

On Sun, Dec 9, 2012 at 10:38 PM, Andrew McNabb  wrote:
> On Fri, Dec 07, 2012 at 05:02:26PM -0500, PJ Eby wrote:
>> If the packages have files in conflict, they won't be both installed.
>> If they don't have files in conflict, there's nothing important to be
>> informed of.  If one is installing pexpect-u, then one does not need
>> to discover that it is a successor of pexpect.
>
> In the specific case of pexpect and pexpect-u, the files don't actually
> conflict.  The pexpect package includes a "pexpect.py" file, while
> pexpect-u includes a "pexpect/" directory.  These conflict, but not in
> the easily detectable sense.

Excellent!  A concrete non-file use case.  Setuptools handles this
particular scenario by including a list of top-level module or package
names, but newer tools ought to look out for this scenario, too.
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Stephen J. Turnbull]

PJ Eby writes:

 > By "clear", I mean "free of prior assumptions".

Ah, well, I guess I've just run into a personal limitation.  I can't
imagine thinking that is "free of prior assumptions".  Not my
own, and not by others, either.

So, unfortunately, I was left with the conventional opposition in
thinking: "clear" vs. "muddy".  That impression was only strengthened
by the phrase "vs. simply copying fields from distro tools."

 > Put together, the phrase "clear thinking on concrete use cases" means
 > (at least to me), "dropping all preconceptions of the existing design
 > and starting over from square one, to ask how best the problem may be
 > solved, using specific examples as a guide rather than using
 > generalities."

Sure, but ISTM that's the opposite of what you've actually been doing,
at least in terms of contributing to my understanding.  One obstacle
to discussion you have contributed to overcoming in my thinking is the
big generality that the packager (ie, the person writing the metadata)
is in a position to recommend "good behavior" to the installation
tool, vs. being in a position to point out "relevant considerations"
for users and tools installing the packager's product.

Until that generality is formulated and expressed, it's very difficult
to see why the examples and particular solutions to use cases that
various proponents have described fail to address some real problems.
It was difficult for me to see, at first, what distinction was
actually being made.

Specifically, I thought that the question about "Obsoletes" vs.
"Obsoleted-By" was about which package should be considered
authoritative about obsolescence.  That is a reasonable distinction
for that particular discussion, but there is a deeper, and general,
principle behind that.  Namely, "metadata is descriptive, not
prescriptive."  Of course once one understands that principle, the
names of the fields don't matter so much, but it is helpful for
"naive" users of the metadata if the field names strongly connote
description of the package rather than behavior of the tool.


___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Andrew McNabb]

On Fri, Dec 07, 2012 at 05:02:26PM -0500, PJ Eby wrote:
> If the packages have files in conflict, they won't be both installed.
> If they don't have files in conflict, there's nothing important to be
> informed of.  If one is installing pexpect-u, then one does not need
> to discover that it is a successor of pexpect.

In the specific case of pexpect and pexpect-u, the files don't actually
conflict.  The pexpect package includes a "pexpect.py" file, while
pexpect-u includes a "pexpect/" directory.  These conflict, but not in
the easily detectable sense.

--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

On Sun, Dec 9, 2012 at 8:48 PM, Stephen J. Turnbull  wrote:
> PJ Eby writes:
>  > This is a good example of what I meant about clear thinking on
>  > concrete use cases, vs. simply copying fields from distro tools.  In
>  > the distro world, these kinds of fields reflect the *results* of
>  > research and decision-making about compatibility.  Whereas, in our
>  > "upstream" world, the purpose of the fields is to provide downstream
>  > repackagers and integrators with the source materials for such
>  > research.
>
> I agree with the meaning of the above paragraph, but would like to
> dissociate myself from the comparison implied by the expression "clear
> thinking".

What comparison is that?

By "clear", I mean "free of prior assumptions".   The assumptions that
made the discussion difficult weren't just about the use cases
themselves, but about the environments, tools, organizations,
concepts, etc. surrounding those use cases.  Indeed, even the
assumption of what should *qualify* as a "use case" was a stumbling
block on occasion.  ;-)

And by "thinking", I mean, "considering alternatives and
consequences", as distinct from debating the merits of a specific
position.

Put together, the phrase "clear thinking on concrete use cases" means
(at least to me), "dropping all preconceptions of the existing design
and starting over from square one, to ask how best the problem may be
solved, using specific examples as a guide rather than using
generalities."  Generalities not rooted in concrete examples have a
way of leading to non-terminating discussions.  ;-)

Starting over a discussion in this fashion isn't easy, but the results
are usually worth it.  I appreciate Nick and Daniel's patience in
particular.
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Stephen J. Turnbull]

PJ Eby writes:

 > That being said, I don't object to having the ability for either of
 > them to do so: the utility of the field is *much* enhanced once its
 > connection to installation tools is gone, since a wider variety of
 > issues can be described without inconveniencing users.

+1 to "describing".  A metadata format should not specify tool
behavior, and should use behavior-neutral nomenclature.  Rather, use
cases that seem probable or perhaps wrong-headed should inform the
design.  Nevertheless, actual decisions about behavior should be left
to the tool authors.

 > This is a good example of what I meant about clear thinking on
 > concrete use cases, vs. simply copying fields from distro tools.  In
 > the distro world, these kinds of fields reflect the *results* of
 > research and decision-making about compatibility.  Whereas, in our
 > "upstream" world, the purpose of the fields is to provide downstream
 > repackagers and integrators with the source materials for such
 > research.

I agree with the meaning of the above paragraph, but would like to
dissociate myself from the comparison implied by the expression "clear
thinking".  AFAICS, it's different assumptions about use cases that
drives the difference in prescriptions here.
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

On Sun, Dec 9, 2012 at 12:54 AM, Nick Coghlan  wrote:
> On Sun, Dec 9, 2012 at 6:18 AM, PJ Eby  wrote:
>>
>> On Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan  wrote:
>> > On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby  wrote:
>> >>
>> >> So if package A includes a "Conflicts: B" declaration, I recommend the
>> >> following:
>> >>
>> >> * An attempt to install A with B already present refuses to install A
>> >> without a warning and confirmation
>> >> * An attempt to install B informs the user of the conflict, and
>> >> optionally offers to uninstall A
>> >>
>> >> In this way, any collateral damage to B is avoided, while still making
>> >> the intended "lack of support" declaration clear.
>> >>
>> >> How does that sound?
>> >
>> >
>> > No, that's not the way it works. A conflict is always symmetric, no
>> > matter
>> > who declares it.
>>
>> But that *precisely contradicts* what you said in your previous email:
>>
>> > It's to allow a project to say
>> > *they don't support* installing in parallel with another package.
>>
>> Just because A doesn't support being installed next to B, doesn't mean
>> B doesn't support being installed next to A.  B might work just fine
>> with A installed, and even be explicitly supported by the author of B.
>>  Why should the author of A get to decide what happens to B?  Just
>> because I trust A about A, doesn't mean I should have to trust them
>> about B.
>
>
> If I'm installing both A *and* B, I want to know if *either* project doesn't
> support that configuration. The order in which they get installed should
> *not* have any impact on my finding out that I am using one of my
> dependencies in an unsupported way that may cause me unanticipated problems
> further down the line.

This is probably moot now, but I didn't propose that installation
order matter -- in both scenarios I described, you end up with a
warning and A not installed, regardless of whether A or B were
installed first.

> The author of A *doesn't* get to decide what happens to B, *I* do.

The reason I said, "(de facto)", is because the default behavior of
whatever the next big installation tool is, would be what most users
would've gotten by default.

> They're
> merely providing a heads up that they believe there are problems when using
> their project in conjunction with B. My options will be:
> - use them both anyway (e.g. perhaps after doing some research, I may find
> out the conflict relates solely to a feature of B that I'm not using, so I
> simply update my project documentation to say "do not use feature X from
> project B, as it conflicts with dependency A")
> - choose to continue using A, find another solution for B
> - choose to continue using B, find another solution for A
>
> As a concrete example, there are projects out there that are known not to
> work with gevent's socket monkeypatching, but people don't know that until
> they try it and it blows up in their face.

Here's the question, though: who's going to maintain that list?

I can see gevent wanting to have a compatibility chart page in their
docs, but it seems unlikely they'd want to block installation of
non-gevent-compatible projects or vice versa.  Similarly, I can't see
why any of those other projects would want to block installation of
gevent, or vice versa.

That being said, I don't object to having the ability for either of
them to do so: the utility of the field is *much* enhanced once its
connection to installation tools is gone, since a wider variety of
issues can be described without inconveniencing users.


> I now agree that *enforcing* a conflicts field at install time in a Python
> installer doesn't make any sense, since the nature of Python means it will
> often be easy to sidestep any such issues once you're aware of their
> existence (e.g. by avoiding gevent's monkeypatching features and using
> threads to interact with the uncooperative synchronous library, or by
> splitting your application into multiple processes, some using gevent and
> others synchronous sockets). I also believe that *any* Conflicts declaration
> *should* be backed up with an explicit explanation and rationale for that
> conflict declaration in the project documentation.

Beyond that, I think a reference URL should be included *in the field
itself*, e.g. to a bug report, support ticket, or other page that
documents the incompatibility and will be updated as the situation
changes.  The actual usefulness of the field to anyone "downstream"
seems greatly reduced if they have to go hunting for the information
explaining the compatibility issue(s).

This is a good example of what I meant about clear thinking on
concrete use cases, vs. simply copying fields from distro tools.  In
the distro world, these kinds of fields reflect the *results* of
research and decision-making about compatibility.  Whereas, in our
"upstream" world, the purpose of the fields is to provide downstream
repackagers and integrators with the source materials for such
research.


> So, I still

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Nick Coghlan]

On Sun, Dec 9, 2012 at 6:18 AM, PJ Eby  wrote:

> On Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan  wrote:
> > On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby  wrote:
> >>
> >> So if package A includes a "Conflicts: B" declaration, I recommend the
> >> following:
> >>
> >> * An attempt to install A with B already present refuses to install A
> >> without a warning and confirmation
> >> * An attempt to install B informs the user of the conflict, and
> >> optionally offers to uninstall A
> >>
> >> In this way, any collateral damage to B is avoided, while still making
> >> the intended "lack of support" declaration clear.
> >>
> >> How does that sound?
> >
> >
> > No, that's not the way it works. A conflict is always symmetric, no
> matter
> > who declares it.
>
> But that *precisely contradicts* what you said in your previous email:
>
> > It's to allow a project to say
> > *they don't support* installing in parallel with another package.
>
> Just because A doesn't support being installed next to B, doesn't mean
> B doesn't support being installed next to A.  B might work just fine
> with A installed, and even be explicitly supported by the author of B.
>  Why should the author of A get to decide what happens to B?  Just
> because I trust A about A, doesn't mean I should have to trust them
> about B.
>

If I'm installing both A *and* B, I want to know if *either* project
doesn't support that configuration. The order in which they get installed
should *not* have any impact on my finding out that I am using one of my
dependencies in an unsupported way that may cause me unanticipated problems
further down the line.

The author of A *doesn't* get to decide what happens to B, *I* do. They're
merely providing a heads up that they believe there are problems when using
their project in conjunction with B. My options will be:
- use them both anyway (e.g. perhaps after doing some research, I may find
out the conflict relates solely to a feature of B that I'm not using, so I
simply update my project documentation to say "do not use feature X from
project B, as it conflicts with dependency A")
- choose to continue using A, find another solution for B
- choose to continue using B, find another solution for A

As a concrete example, there are projects out there that are known not to
work with gevent's socket monkeypatching, but people don't know that until
they try it and it blows up in their face.

I now agree that *enforcing* a conflicts field at install time in a Python
installer doesn't make any sense, since the nature of Python means it will
often be easy to sidestep any such issues once you're aware of their
existence (e.g. by avoiding gevent's monkeypatching features and using
threads to interact with the uncooperative synchronous library, or by
splitting your application into multiple processes, some using gevent and
others synchronous sockets). I also believe that *any* Conflicts
declaration *should* be backed up with an explicit explanation and
rationale for that conflict declaration in the project documentation.

Making it impossible to document runtime conflicts in metadata doesn't make
those conflicts go away - it just means they will continue to be documented
in an ad hoc manner on project web sites (if they get documented at all),
making the job of package curation unnecessarily more difficult (since
there is no standard way to document runtime conflicts). Adding a metadata
field doesn't make sure such known conflicts *will* be documented, but it
least makes it possible.

So, I still like the idea of including a Conflicts field, but think a few
points should be made clear:
- the Conflicts field would be for documenting other distributions which
have known issues working together in the same process and thus constitute
an unsupported configuration
- this field would be aimed at package *users*, rather than at installation
tools (although it would still be good if they installation tools supported
scanning a set of packages for known conflicts)
- any use of this field should be backed up with a more detailed
explanation in the project documentation

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Nick Coghlan]

On Sun, Dec 9, 2012 at 8:41 AM, Tres Seaver  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 12/08/2012 05:06 AM, Nick Coghlan wrote:
>
> > Building integrated systems *is hard*. Pretending projects can't
> > conflict just because they're both written in Python isn't sensible,
> > and neither is it sensible to avoid warning users about the the
> > potential for latent defects when particular packages are used in
> > combination.
>
> Building such systems is *too hard* to deletgate to the maintainers of
> every Python distribution registered on the Cheeseshop:  there is too
> much policy involved for the ha'penn'orth of mechanism we are discussing
> here (decentralized inter-project metadata) to support.
>
> Such metadata *cannot* be useful in the general sense, but only in the
> context of a "curated" collection of packages, where the *curator* (not
> the upstream package authors) makes the choices.
>

The authors of major projects are often in a good position to know when
they conflict with other high profile projects and thus can't be used
reliably in the same system. Now, *most* of the time, if there's a genuine
conflict between two Python packages, it's going to be at install time -
two projects attempting to install the same file obviously can't coexist on
a single system (distribute and setuptools, for example, conflict at this
level - they both want to own the "setuptools" and "easy_install" names).
However, Python has plenty of other global state too (the codec registry,
the import system, monkeypatching), and there is potential for conflict
over underlying OS level resources.

So let's look at the case of collections of Python packages that *are*
curated. Maybe I'm a Linux distro packager, looking to automate the
conversion to distro packages. Maybe I'm a toolsmith for a large
corporation trying to build a curated set of packages for internal use
(clearly indicating to my internal users which ones don't play nicely with
each other and thus shouldn't be used together in the same project).

Regardless of the reason, I'm the curator for a collection of Python
packages. How shall I express the conflicts I have identified? Shall I go
invent my own metadata system? Shall I be forced to choose a particular
platform-specific dependency management system? How shall upstream authors
communicate to *me* the conflicts that they're already aware of?

Or, hey, there's this nice shiny cross-platform dependency management
system *right here*. Maybe they'll be nice enough to consider handling *my*
use case as well, even if it's a use case *they* don't care about.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/08/2012 05:06 AM, Nick Coghlan wrote:

> Building integrated systems *is hard*. Pretending projects can't
> conflict just because they're both written in Python isn't sensible,
> and neither is it sensible to avoid warning users about the the
> potential for latent defects when particular packages are used in
> combination.

Building such systems is *too hard* to deletgate to the maintainers of
every Python distribution registered on the Cheeseshop:  there is too
much policy involved for the ha'penn'orth of mechanism we are discussing
here (decentralized inter-project metadata) to support.

Such metadata *cannot* be useful in the general sense, but only in the
context of a "curated" collection of packages, where the *curator* (not
the upstream package authors) makes the choices.



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDDwioACgkQ+gerLs4ltQ4rOACghpN5x+k0w0Umn20AG1WOvYkq
KQsAnibXQtbTnmbrPaMaVEfLH7W496lk
=WAh9
-END PGP SIGNATURE-

___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[MRAB]

On 2012-12-08 20:18, PJ Eby wrote:

On Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan  wrote:

On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby  wrote:


So if package A includes a "Conflicts: B" declaration, I recommend the
following:

* An attempt to install A with B already present refuses to install A
without a warning and confirmation
* An attempt to install B informs the user of the conflict, and
optionally offers to uninstall A

In this way, any collateral damage to B is avoided, while still making
the intended "lack of support" declaration clear.

How does that sound?



No, that's not the way it works. A conflict is always symmetric, no matter
who declares it.


But that *precisely contradicts* what you said in your previous email:


It's to allow a project to say
*they don't support* installing in parallel with another package.


Just because A doesn't support being installed next to B, doesn't mean
B doesn't support being installed next to A.  B might work just fine
with A installed, and even be explicitly supported by the author of B.
  Why should the author of A get to decide what happens to B?  Just
because I trust A about A, doesn't mean I should have to trust them
about B.


[snip]
If package A says that it conflicts with package B, it may or may not
be symmetrical, because it's possible that package B has been updated
since the author of package A discovered the conflict, so it's
important that the user is told which package is complaining about the
conflict, the one that is being installed or the one that is already
installed.

It may also be helpful if the package that includes the "Conflicts"
declaration specifies which version of the other package it was last
tested against in case there is a more recent version of the other
package that does not cause the conflict, or, indeed, that there's a
more recent version of the package that includes the "Conflicts"
declaration that does not cause the conflict.

___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

On Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan  wrote:
> On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby  wrote:
>>
>> So if package A includes a "Conflicts: B" declaration, I recommend the
>> following:
>>
>> * An attempt to install A with B already present refuses to install A
>> without a warning and confirmation
>> * An attempt to install B informs the user of the conflict, and
>> optionally offers to uninstall A
>>
>> In this way, any collateral damage to B is avoided, while still making
>> the intended "lack of support" declaration clear.
>>
>> How does that sound?
>
>
> No, that's not the way it works. A conflict is always symmetric, no matter
> who declares it.

But that *precisely contradicts* what you said in your previous email:

> It's to allow a project to say
> *they don't support* installing in parallel with another package.

Just because A doesn't support being installed next to B, doesn't mean
B doesn't support being installed next to A.  B might work just fine
with A installed, and even be explicitly supported by the author of B.
 Why should the author of A get to decide what happens to B?  Just
because I trust A about A, doesn't mean I should have to trust them
about B.

Look, I really don't care about the individual fields' definitions
that much.  I care about only one thing: A shouldn't get to (de facto)
dictate what happens to B.  If you *really* want the behavior to be
symmetrical, then it should *only* be symmetrical if both A and B
*agree* they are in conflict.  (i.e., both refer to the other in their
conflict fields).  Otherwise, it should only be a warning.

There are tons of other things that I could argue here about the
positions you've laid out.  But all I *really* care about is that we
not define fields in such a way as to permit or encourage
inter-package warfare -- intentional or not.  Solutions acceptable to
me include (in no particular order):

* Make declarations affect only the declarer (as with Obsoleted-By)
* Make declarations only warn users, not block installation or result
in uninstallation
* Have no automated action at all, and document them as intended for
downstream repackagers only
* Toss the field entirely
* Make the field include a context (e.g. a distro name), so that only
tools explicitly told you're operating in that context pay attention
* Use the new metadata extension vocabularies to define hints for
specific downstream packaging tools and systems
* Replace "conflicts" with a specification of resources actually used
by the project, so that such conflicts can be automatically detected
without needing to target a specific project

And there are probably others I haven't thought of yet.  If you can be
clearer about what it is you want from the Conflicts field *other*
than just wanting it to stay as is (or perhaps *why* you would like to
have the Python infrastructure side with project A over project B,
irrespective of which project is A and which one is B), then perhaps I
can come up with others.
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Nick Coghlan]

On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby  wrote:

> So if package A includes a "Conflicts: B" declaration, I recommend the
> following:
>
> * An attempt to install A with B already present refuses to install A
> without a warning and confirmation
> * An attempt to install B informs the user of the conflict, and
> optionally offers to uninstall A
>
> In this way, any collateral damage to B is avoided, while still making
> the intended "lack of support" declaration clear.
>
> How does that sound?
>

No, that's not the way it works. A conflict is always symmetric, no matter
who declares it.

The beneficiary of these notifications is the aggregator attempting to
build a systematically coherent system, rather than one with latent
incompatibilities waiting to bite them at run time. It doesn't *matter* if
"A conflicts with B" or "B conflicts with A", you cannot have a system with
both of them installed that will be supported by the developers of both A
*and* B.

Now, this beneficiary *may* be the packagers for a Linux distribution, but
it may also be a larger Python distribution (ActiveState, EPD, etc), a web
application developer, a desktop application developer, a system integrator
for a large-scale distributed system, or anyone else that combines and
deploys an integrated set of packages (even those a developer installs on
their personal workstation).

It's up to the user to decide who they want to believe. Now, it may be
that, for a given use case, the end user doesn't actually care about the
potential conflict (e.g. they've done their own research and determined
that the conflicting behaviour doesn't affect their system) - that's then a
design decision in the installation tools as to whether or not they want to
make it easy for users to override the metadata. In the Linux distro case,
the installer *and* most of the metadata are largely provided by the same
people, so yum/rpm/etc generally *don't* make it easy to install
conflicting packages. Python installers are in a different situation
though, so forced installs are likely to be an expected feature (in fact, I
expect the more likely outcome given the status quo is that the default
behaviour will be a warning at installation time with an option to request
enforcement of "no conflicts").

Building integrated systems *is hard*. Pretending projects can't conflict
just because they're both written in Python isn't sensible, and neither is
it sensible to avoid warning users about the the potential for latent
defects when particular packages are used in combination.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

On Fri, Dec 7, 2012 at 8:33 PM, Nick Coghlan  wrote:
> That's not what a Conflicts field is for. It's to allow a project to say
> *they don't support* installing in parallel with another package.

If that's the actual intended use case, the PEP needs some revision.
In particular, if there's a behavioral recommendation for installer
tools, it should be to avoid installing the project that *declares*
the conflict, rather than the one that is the object of that
declaration.  ;-)

In any case, as I said before, I don't have an issue with the fields
all being declared as being for informational purposes only.  My issue
is only with recommendations for automated tool behavior that permit
one project's author to exercise authority over another project's
installation.  If the fields are defined in such a way that an author
can only shoot *themselves* in the foot with a bad declaration, that's
fine by me.

So if package A includes a "Conflicts: B" declaration, I recommend the
following:

* An attempt to install A with B already present refuses to install A
without a warning and confirmation
* An attempt to install B informs the user of the conflict, and
optionally offers to uninstall A

In this way, any collateral damage to B is avoided, while still making
the intended "lack of support" declaration clear.

How does that sound?
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Nick Coghlan]

On Sat, Dec 8, 2012 at 8:02 AM, PJ Eby  wrote:

> > *) Not all packages built build on top of that system.  There are rpm
> > packages provided by upstreams that users attempt (to greater and lesser
> > degrees of success) to install on SuSE, RHEL, Fedora, Mandriva, etc.
>  There
> > are debs built for Ubuntu that people attempt to install onto Debian.
>
> Sure.  But the reference points still exist, and there is a layer of
> indirection between "packager" and "developer", even in the case where
> the packager and developer are the same person or organization.  In
> the Python case, there is usually no such indirection, outside of
> curated systems like SciPy et al.  (Even there, most of what
> third-party packaging is about in the Python world is taking care of
> binary builds.)
>
> Again, it's islands in the ocean vs. pools on land.
>

To strain the analogy, the main value of these fields exists on the beach:
at the point where you need to impedance match between the Python community
and another packaging community.

The ideal is to be able to get a point where you can point an automated
tool at a project on PyPI and say "give me that, only packaged as
RPM/deb/whatever, with appropriate distro specific metadata". Such a tool
is obviously going to be distro specific, since it is going to have to do
some remapping based on file names to pick up existing distro packages, but
it *also* needs upstream metadata.

Even in a distro, a "Conflicts:" field often *does* denote runtime
conflicts (e.g. over a particular network port), because, as you say,
filesystem level conflicts will usually be picked up automatically. The
distro philosophy is to say "OK, we simply won't let you install
conflicting projects at the same time, so you won't be surprised later by a
conflict that only shows up if you happen to run them both at the same
time". It's designed to turn a complex, hard to debug, problem into a
simple, explicit error at installation time.

People build complex systems (especially web apps) based on the PyPI
ecosystem, and the upstream communities *can* assist in flagging potential
issues in advance. If people start putting bad metadata in their projects,
then that's just a bug to be dealt with like any other.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Donald Stufft]

On Friday, December 7, 2012 at 8:33 PM, Nick Coghlan wrote:
> That's not what a Conflicts field is for. It's to allow a project to say 
> *they don't support* installing in parallel with another package. It doesn't 
> matter why it's unsupported, it's making a conflict perceived by the project 
> explicit in their metadata.
> 
> Such a field is designed to convey information to users about *supported* 
> configurations, regardless of whether or not they happen to work for a given 
> use case. If a user believes a declared conflict is in error, and having the 
> two installed in parallel is important to them, they can:
> 1. Use virtual environments to keep the two projects isolated from each other
> 2. Use an installer that ignores Conflicts information (which will be all of 
> them, since that's the status quo)
> 3. Make their case to the upstream project that the conflict has been 
> resolved, and installing the two in parallel no longer causes issues
4. Use the eventual --force flag that any installer that supported conflicts is 
likely to include ;) 

___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Nick Coghlan]

On Fri, Dec 7, 2012 at 3:47 PM, PJ Eby  wrote:

> In effect, a "conflicts" field actually *creates* conflicts and
> maintenance burdens where they did not previously exist, because even
> after the conflict no longer really existed, an automated tool would
> have prevented PyDispatch from being installed, or, per your
> suggestion above, unnecessarily *uninstalled* it after a user
> installed RuleDispatch.
>

That's not what a Conflicts field is for. It's to allow a project to say
*they don't support* installing in parallel with another package. It
doesn't matter why it's unsupported, it's making a conflict perceived by
the project explicit in their metadata.

Such a field is designed to convey information to users about *supported*
configurations, regardless of whether or not they happen to work for a
given use case. If a user believes a declared conflict is in error, and
having the two installed in parallel is important to them, they can:
1. Use virtual environments to keep the two projects isolated from each
other
2. Use an installer that ignores Conflicts information (which will be all
of them, since that's the status quo)
3. Make their case to the upstream project that the conflict has been
resolved, and installing the two in parallel no longer causes issues

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

On Fri, Dec 7, 2012 at 12:01 PM, Toshio Kuratomi  wrote:
> On Fri, Dec 07, 2012 at 01:18:40AM -0500, PJ Eby wrote:
>> On Thu, Dec 6, 2012 at 1:49 AM, Toshio Kuratomi  wrote:
>> > On Wed, Dec 05, 2012 at 07:34:41PM -0500, PJ Eby wrote:
>> >> Nobody has actually proposed a better one, outside of package renaming
>> >> -- and that example featured an author who could just as easily have
>> >> used an obsoleted-by field.
>> >>
>> > How about pexpect and pextpect-u as a better example?
>>
>> Perhaps you could explain?  I'm not familiar with those projects.
>>
>
> pexepect was last released in 2008.  Upstream went silent with unanswered
> bugs in its tracker and no mailing list.  A fork of pexpect was created that
> addressed the issue of unicode type in python2, a python3 port, and has
> slowly evolvd since then.
>
> I see that the original upstream has made some commits to their source
> repository since the fork was created although there has still been no new
> release.

And what problem are you saying which fields would have solved (or
which benefits they would have provided), for whom?

If the packages have files in conflict, they won't be both installed.
If they don't have files in conflict, there's nothing important to be
informed of.  If one is installing pexpect-u, then one does not need
to discover that it is a successor of pexpect.  If one is installing
pexpect, it might be useful to know that pexpect-u exists, but one
can't simply discover that from an Obsoletes field on pexpect-u.
However, even if one did discover it, this would merely constitute an
*advertisement* of pexpect-u's existence, not a *requirement* that it
be used in place.  A tool cannot know, without other affirmative user
action, that it is actually a good assumption to use the advertised
replacement.

In the distro world, a user has *already* taken this affirmative
action by choosing which repository to source packages from, on an
implicit contract that this source is up to the job of managing his
needs across multiple packages.  Or, if they choose to source an
off-brand or upstream package, they are taking affirmative action to
risk it.

In the Python world, there is no notion of a "repository", aside from
a handful of managed Python distros, which have their own, distinct
packaging methods and distribution tools.  So there is no affirmative
contract of trust regarding *inter-project* relationships.

It is precisely this lack that is why the metadata spec has gone
mostly unused since its inception about a decade ago.  Nobody really
knows what to "provide" or "require", or in what context they would
actually be "obsoleting" anything that isn't their own package, or a
package they've forked.

But if you live mainly in the distro world, this concept seems absurd,
and the fields *obviously* useful.  But that's because you're swimming
in an ocean of context that doesn't exist on dry land.  You're saying
that *of course* swimming fins are useful...  if you live in the
ocean.

And I, living on dry land, am saying that *sure* they are...  but only
in a swimming pool or a pond, and we don't have very many of those
here in dry Python-land.  And the people who run the swimming pools
have thoughtfully already provided their own.  Do we need to
standardize swim fin sizes for people who mostly live on dry land?

The flip side of this, btw, is that there's an implicit contract in
the Python world that there is generally only "the" package - not "the
package as patched and re-packaged by vendors X, Y, and Z".  If I
install python project foo, version 1.2, I expect it to be the *same*
foo-1.2, with the *same metadata*, *no matter where I got it from*.

And so, this assumption is our "air" to your "water".  We know that
pools and ponds (curated Python distros) are different, as an
exception to this rule, just as you know that reefs and islands
(uncurated repositories, search engines, and upstream-built packages)
are different, as an exception to your assumption that "the package I
get is intended to play well with everything else in my system."

(This of course is why many distro managers are suspicious of
language-specific or other sorts of vertical package management tools
- they seem as pointless as wheels in the water, solving problems you
don't have, and creating new problems for you at the same time.
Unfortunately, people on land will keep inventing them, because they
have a different set of problems to solve -- some of which are
actually created by the ocean-oriented tools.  For example, virtualenv
and its predecessors were developed to solve the "problem" of a single
integrated environment, even though that integrated environment is the
"solution" from a distro perspective.)


> *) Not all packages built build on top of that system.  There are rpm
> packages provided by upstreams that users attempt (to greater and lesser
> degrees of success) to install on SuSE, RHEL, Fedora, Mandriva, etc.  There
> are debs built for Ubuntu that people atte

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Toshio Kuratomi]

On Fri, Dec 07, 2012 at 01:18:40AM -0500, PJ Eby wrote:
> On Thu, Dec 6, 2012 at 1:49 AM, Toshio Kuratomi  wrote:
> > On Wed, Dec 05, 2012 at 07:34:41PM -0500, PJ Eby wrote:
> >> On Wed, Dec 5, 2012 at 6:07 PM, Donald Stufft  
> >> wrote:
> >>
> >> Nobody has actually proposed a better one, outside of package renaming
> >> -- and that example featured an author who could just as easily have
> >> used an obsoleted-by field.
> >>
> > How about pexpect and pextpect-u as a better example?
> 
> Perhaps you could explain?  I'm not familiar with those projects.
> 

pexepect was last released in 2008.  Upstream went silent with unanswered
bugs in its tracker and no mailing list.  A fork of pexpect was created that
addressed the issue of unicode type in python2, a python3 port, and has
slowly evolvd since then.

I see that the original upstream has made some commits to their source
repository since the fork was created although there has still been no new
release.

> > Note that although well-managed Linux distros attempt to control random
> > forking internally, the distro package managers don't prevent people from
> > installing from third parties.  So Ubuntu PPAs, upstreams that provide their
> > own rpms/debs, and major third party repos (for instance, rpmfusion as
> > an add-on repo to Fedora) all have and sometimes (mis)use the ability to
> > Obsolete packages in the base repository.
> 
> But in each of these cases, the packages are being defined *with
> reference to* some underlying vision of what the distro (or even "a
> distro") is.  An Ubuntu PPA, if I understand correctly, is still
> *building an Ubuntu system*.  Python packaging as a whole lacks such
> frames of reference.  A forked distro is still a distro, and it's a
> fork *of something*.  Rpmfusion is defining an enhanced Fedora, not
> slinging random unrelated packages about.
> 
Uhm that's both true and false as any complex system is.
rpm and deb are just packaging formats.  So:

*) Not all packages built build on top of that system.  There are rpm
packages provided by upstreams that users attempt (to greater and lesser
degrees of success) to install on SuSE, RHEL, Fedora, Mandriva, etc.  There
are debs built for Ubuntu that people attempt to install onto Debian.

*) PPAs and rpmfusion may both build on top of an existing system but they
can change the underlying structure, replacing components that other pieces
of the base system depend on.  You talk about the setuptools and distribute
problem on pypi there's absolutley nothing that prevents someone from
building a PPA or a package in a third-party rpm repository that packages
a setuptools that Obsoletes: distribute or a distribute package that
Obsoletes: setuptools.

> > The install tools can then choose how they wish to deal with those caveats.
> > Some example strategies: choose to prompt the user as to which to install,
> > choose to always treat the fields as human-informational only, mark some
> > repositories as being trusted to contain packages where these fields are
> > active and other repositories where the fields are ignored.
> 
> A peculiar phenomenon: every defense of these fields seems to refer
> almost exclusively to how the problems could be fixed or why the
> problems aren't that bad, rather than *how useful the fields would be*
> in real-world scenarios.  In some cases, the argument for the fields'
> safety actually runs *counter* to their usefulness, e.g., the fields
> aren't that bad because we could make them have a limited function or
> no function at all.  Isn't lack of usefulness generally considered an
> argument for *not* including a feature?  ;-)
>
If you constantly forget why the fields are useful, then I suppose you'll
always believe that :-)

-Toshio


pgpL8jo6bw502.pgp
Description: PGP signature
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

On Thu, Dec 6, 2012 at 1:49 AM, Toshio Kuratomi  wrote:
> On Wed, Dec 05, 2012 at 07:34:41PM -0500, PJ Eby wrote:
>> On Wed, Dec 5, 2012 at 6:07 PM, Donald Stufft  
>> wrote:
>>
>> Nobody has actually proposed a better one, outside of package renaming
>> -- and that example featured an author who could just as easily have
>> used an obsoleted-by field.
>>
> How about pexpect and pextpect-u as a better example?

Perhaps you could explain?  I'm not familiar with those projects.

> Note that although well-managed Linux distros attempt to control random
> forking internally, the distro package managers don't prevent people from
> installing from third parties.  So Ubuntu PPAs, upstreams that provide their
> own rpms/debs, and major third party repos (for instance, rpmfusion as
> an add-on repo to Fedora) all have and sometimes (mis)use the ability to
> Obsolete packages in the base repository.

But in each of these cases, the packages are being defined *with
reference to* some underlying vision of what the distro (or even "a
distro") is.  An Ubuntu PPA, if I understand correctly, is still
*building an Ubuntu system*.  Python packaging as a whole lacks such
frames of reference.  A forked distro is still a distro, and it's a
fork *of something*.  Rpmfusion is defining an enhanced Fedora, not
slinging random unrelated packages about.

If there's a distro analogy to PyPI, it seems to me that something
like RpmFind would be closer: it's just a free-for-all of packages,
with the user needing to decide for themselves whether installing
something from a foreign distro will or won't blow up their system.
(E.g., because their native distro and the foreign one use a different
"provides" taxonomy.)

RpmFind itself can't solve anybody's issues with conflicts or
obsoletes; all it can do is search the data that's there.

But unlike PyPI, RpmFind can at least tell you which vision of "a
distro" a particular package was intended for.  ;-)


> The ability for this class of fields to cause harm is not, to me,
> a compelling argument not to include them.

But it is absolutely not a compelling argument *to* include them, and
the actual arguments for them are pretty thin on the ground.

The real knockdown is that in the PyPI environment, there aren't any
automated use cases that don't produce collateral damage (outside of
advisories about Obsoleted-By projects).


> It could be an argument to
> explicitly tell implementers of install tools that they all have caveats
> when used with pypi and similar unpoliced community package repositories.

AFAIK, there are only a handful of curated repositories: Scipy,
Enthought, and ActiveState come to mind.  These are essentially
"python distros", and they might certainly have reason to build policy
into their metadata.  I expect, however, that they would not want the
*package* authors declaring their own conflicts or obsolescence, so
I'm not sure how the metadata spec will help them.  Has anyone asked
for their input or experience?  It seems pointless to speculate on
what they might or might not need for curated distribution.  (I'm
pretty sure Enthought has their own install tools, not sure about the
other two.)

> The install tools can then choose how they wish to deal with those caveats.
> Some example strategies: choose to prompt the user as to which to install,
> choose to always treat the fields as human-informational only, mark some
> repositories as being trusted to contain packages where these fields are
> active and other repositories where the fields are ignored.

A peculiar phenomenon: every defense of these fields seems to refer
almost exclusively to how the problems could be fixed or why the
problems aren't that bad, rather than *how useful the fields would be*
in real-world scenarios.  In some cases, the argument for the fields'
safety actually runs *counter* to their usefulness, e.g., the fields
aren't that bad because we could make them have a limited function or
no function at all.  Isn't lack of usefulness generally considered an
argument for *not* including a feature?  ;-)
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

On Thu, Dec 6, 2012 at 9:58 AM, Vinay Sajip  wrote:
> Daniel Holth  gmail.com> writes:
>
>> The wheel implementation makes sure all the metadata (the .dist-info 
>> directory)
>> is at the end of the .zip archive. It's possible to read the metadata with a
>> single HTTP partial request for the end of the archive without downloading 
>> the
>> entire archive.
>
> Sounds good, but can you point to any example code which does this? As I
> understand it, for .zip files you have to read the last part of the file to 
> get a
> pointer to the directory, then read that to find where each file in the 
> archive
> is, then seek to a specific position to read the file contents.

ISTR that this is especially true for zipimport: I think it depends on
a zipfile signature being present at the *end* of the file.

Certainly, the standard for .exe and shell wrappers for zipfiles is to
place them at the beginning of the file, rather than the end.
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

On Thu, Dec 6, 2012 at 8:39 AM, Daniel Holth  wrote:
> It will be Obsoleted-By:. The "drop in replacement" requirement will be
> removed. The package manager will say "you are using these obsolete
> packages; check out these non-obsolete ones" but will not automatically pull
> the replacement without a Requires tag.

Sounds fine to me.

> I will probably add the unambiguous Conflicts: tag "uninstall this other
> package if I am installed".

Please don't.  See my lengthy posts from the previous PEP 345 retread
discussion for why, or ask MRAB to succinctly summarize them as he did
so brilliantly with the obsoletes/obsoleted-by issue.  ;-)

I'll take a stab at a short version, though: a conflict (other than
filename conflict) is not an installation-time property of a single
project, but rather a *runtime* property of an overall system to which
the projects are being installed, including configuration that is out
of scope for a Python-specific installation tool to manage.  In
addition, even declaring overall conflicts as a *mere shorthand* for
an existing file conflict creates the possibility of stale conflict
information!

For example, RuleDispatch vs. PyDispatcher: at one time both provided
a "dispatch" package, but if RuleDispatch declared PyDispatcher
conflicting, the declaration would quickly have become outdated:
PyDispatcher soon renamed its provided package to resolve the
conflict.  A file-based system can both detect and resolve this
conflict (or lack thereof) automatically, whereas a manual "Conflicts"
notation must be maintained by the author(s) of one or both packages
and removed when out of date.

In effect, a "conflicts" field actually *creates* conflicts and
maintenance burdens where they did not previously exist, because even
after the conflict no longer really existed, an automated tool would
have prevented PyDispatch from being installed, or, per your
suggestion above, unnecessarily *uninstalled* it after a user
installed RuleDispatch.

And unlike the Obsoletes->Obsoleted-By change, I do not know of any
similar way to salvage the idea of a Conflicts field, without
reference to some mediating authority that manages the information on
behalf of an overall system into which the projects are being fitted.
But in that case, neither of the projects really owns the declaration
- it's more like Zope (say) would need a list of plugins that conflict
with each other, or they could declare that they conflict when
activated in the same instance.

A generic Python installer, however, that doesn't know about Zope
instances or Apache vhosts or Django apps or any other "environment of
conflict", can't assume that *mere installation* constitutes a
conflict!  It doesn't know, for example, whether code from two
simultaneously-installed packages will ever even be *imported* in the
same process, let alone whether their specific conflicting features
will be used in that process.

This effectively ensures that in general, Python installation tools
can *only* rely on file-based conflicts as being denotable by project
metadata -- and even then, it's better to stick with *actual* file
conflicts rather than predicted ones, to avoid the type of logjam
described above.


P.S. Sorry once again to drag you through all this at the last minute;
I just sort of assumed you picked up where Alexis left off on the
previous attempt at an update to PEP 345 and didn't pay close enough
attention to earlier drafts.
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Daniel Holth]

On Thu, Dec 6, 2012 at 11:30 AM, Vinay Sajip wrote:

> Daniel Holth  gmail.com> writes:
>
> > You have to make a maximum of 3 requests: one for the directory pointer,
> one
> > for the directory, and one for the file you want. It's not particularly
> > difficult to make an HTTP-backed seekable file object to pass to
> ZipFile() for
> > this purpose but I don't have an example. Normally the last few k of the
> file
> > will contain all 3 pieces. 8k or 16k would be a good guess.
>
> I don't need an example for doing it with multiple HTTP requests. I only
> asked
> for an example because you said one could read the metadata "with a single
> HTTP partial request", and I couldn't see how it could always be done with
> a
> single request.
>
> PEP 427 is mute on the subject of zip file comments in a .whl, but perhaps
> it
> shouldn't be. IIUC, the directory of the zip file *could* be further from
> the end
> of the file by more than 16K, due to the possible presence of a
> pathologically
> large comment in the end record.


It's just a "usually works" optimization that might be fun when bandwidth
is more important than round trip times. The distance between the directory
and the end of the file depends on the size of the directory. Django's is
an extreme case at nearly half a meg; most are much smaller.

On many filesystems it is cheap to create a sparse file the size of the
entire archive and write the partial requests into it. The OS doesn't
actually store all the 0's.

The other reason wheel puts the metadata at the end is so the metadata can
be re-written efficiently without re-writing the entire zipfile. The wheel
project implements ZipFile.pop() which truncates the last file from a
(normal) zip archive. This is especially useful when the last file is the
attached digital signature.
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Vinay Sajip]

Daniel Holth  gmail.com> writes:

> You have to make a maximum of 3 requests: one for the directory pointer, one
> for the directory, and one for the file you want. It's not particularly
> difficult to make an HTTP-backed seekable file object to pass to ZipFile() for
> this purpose but I don't have an example. Normally the last few k of the file
> will contain all 3 pieces. 8k or 16k would be a good guess.

I don't need an example for doing it with multiple HTTP requests. I only asked
for an example because you said one could read the metadata "with a single
HTTP partial request", and I couldn't see how it could always be done with a
single request.

PEP 427 is mute on the subject of zip file comments in a .whl, but perhaps it
shouldn't be. IIUC, the directory of the zip file *could* be further from the 
end
of the file by more than 16K, due to the possible presence of a pathologically
large comment in the end record.

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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Ronald Oussoren]

On 6 Dec, 2012, at 15:58, Vinay Sajip  wrote:

> Daniel Holth  gmail.com> writes:
> 
>> The wheel implementation makes sure all the metadata (the .dist-info 
>> directory)
>> is at the end of the .zip archive. It's possible to read the metadata with a
>> single HTTP partial request for the end of the archive without downloading 
>> the
>> entire archive.
> 
> Sounds good, but can you point to any example code which does this? As I
> understand it, for .zip files you have to read the last part of the file to 
> get a
> pointer to the directory, then read that to find where each file in the 
> archive
> is, then seek to a specific position to read the file contents.

Because zipfiles can be appended to other files (for example when creating a 
self-extracting archive) the zipfile module maintains the file offset of the 
start of a zipfile. The code in the stdlib doesn't appear to test that the 
zipfile is at a positive offset in the file, therefore with some luck the 
following will work: 

* Download the last 10K of the archive (adjust the size to taste, it should be 
large enough to contain the zipfile directory and the file you are trying to 
read)

* Create a zipfile.ZipFile

* Read the zipfile member.

If that doesn't work you'll have to create a temporary file of the right size 
and place the downloaded bit at the end of that file.

BTW. Another (more hacky) alternative is to place the interesting bits of 
dist-info at the start of the zipfile, then you only need to download the first 
bit of the archive and can then extract the bits you need by parsing the local 
file headers (zipfiles contain both a directory at the end of the zipfile and a 
local header stored just before the file data). 

Ronald
> 
> 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/ronaldoussoren%40mac.com

___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Daniel Holth]

On Thu, Dec 6, 2012 at 9:58 AM, Vinay Sajip  wrote:

> Daniel Holth  gmail.com> writes:
>
> > The wheel implementation makes sure all the metadata (the .dist-info
> directory)
> > is at the end of the .zip archive. It's possible to read the metadata
> with a
> > single HTTP partial request for the end of the archive without
> downloading the
> > entire archive.
>
> Sounds good, but can you point to any example code which does this? As I
> understand it, for .zip files you have to read the last part of the file
> to get a
> pointer to the directory, then read that to find where each file in the
> archive
> is, then seek to a specific position to read the file contents.


You have to make a maximum of 3 requests: one for the directory pointer,
one for the directory, and one for the file you want. It's not particularly
difficult to make an HTTP-backed seekable file object to pass to ZipFile()
for this purpose but I don't have an example. Normally the last few k of
the file will contain all 3 pieces. 8k or 16k would be a good guess.
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Vinay Sajip]

Daniel Holth  gmail.com> writes:

> The wheel implementation makes sure all the metadata (the .dist-info 
> directory)
> is at the end of the .zip archive. It's possible to read the metadata with a
> single HTTP partial request for the end of the archive without downloading the
> entire archive.

Sounds good, but can you point to any example code which does this? As I
understand it, for .zip files you have to read the last part of the file to get 
a
pointer to the directory, then read that to find where each file in the archive
is, then seek to a specific position to read the file contents.

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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Daniel Holth]

On Thu, Dec 6, 2012 at 6:33 AM, Donald Stufft wrote:

> On Thursday, December 6, 2012 at 6:28 AM, Vinay Sajip wrote:
>
> Donald Stufft  gmail.com> writes:
>
> Never mind the "Obsoletes" information - even the more useful
> "Requires-Dist"
> information is not exposed via PyPI, even though it appears to be stored
> in the
> database. (Or if it is, please point me to where - I must have missed it.)
>
> Requires-Dist doesn't exist for more than a handful of packages. But PyPI
> exposes
> it via the XMLRPC API, possibly the JSON api as well.
>
>
> Even if this were to be made available, it's presumably obtained from
> PKG-INFO.
> As I understand, this data is not considered reliable - for example, pip
> runs
> egg_info on downloaded packages to get updated information when determining
> dependencies to be downloaded. If the Requires-Dist info in PKG-INFO can't
> be
> relied on, surely less critical information such as Obsoletes can't be
> relied on,
> either?
>
> pip runs egg_info because setuptools does not write out to PKG-INFO what
> the dependencies are (it does write it out to a different text file
> though). But IIRC
> that text file is not guaranteed to exist in the distribution. There's
> also the
> history where pip was trying to preserve as much backwards compat with
> easy_install as it could, and if you used the file that egg_info writes out
> then you'll only get the requirements for the system that the distribution
> was
> packaged on. Any if statements that affect the dependencies won't be
> in effect.
>

It will be Obsoleted-By:. The "drop in replacement" requirement will be
removed. The package manager will say "you are using these obsolete
packages; check out these non-obsolete ones" but will not automatically
pull the replacement without a Requires tag.

I will probably add the unambiguous Conflicts: tag "uninstall this other
package if I am installed".


Many packages (IIRC more than half) have the pre-Metadata-1.2 equivalent of
Requires-Dist: which is the very easy to parse requires.txt. This
information is not reliable because it could depend on conditions in
setup.py. Someone should write a setup.py compiler that determines whether
a package's requirements are conditional or not.


Environment markers (limited Python expressions at the end of Requires-Dist
lines) attempt to make Requires-Dist reliable. You can execute them safely
in your environment to determine whether  a requirement is right for you:

Requires-Dist: pywin32 (>1.0); sys.platform == 'win32'


The wheel implementation makes sure all the metadata (the .dist-info
directory) is at the end of the .zip archive. It's possible to read the
metadata with a single HTTP partial request for the end of the archive
without downloading the entire archive.
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Donald Stufft]

On Thursday, December 6, 2012 at 6:28 AM, Vinay Sajip wrote:
> Donald Stufft  gmail.com (http://gmail.com)> writes:
> 
> Never mind the "Obsoletes" information - even the more useful "Requires-Dist"
> information is not exposed via PyPI, even though it appears to be stored in 
> the
> database. (Or if it is, please point me to where - I must have missed it.)
> 
> 

Requires-Dist doesn't exist for more than a handful of packages. But PyPI 
exposes
it via the XMLRPC API, possibly the JSON api as well. 
> 
> Even if this were to be made available, it's presumably obtained from 
> PKG-INFO.
> As I understand, this data is not considered reliable - for example, pip runs
> egg_info on downloaded packages to get updated information when determining
> dependencies to be downloaded. If the Requires-Dist info in PKG-INFO can't be
> relied on, surely less critical information such as Obsoletes can't be relied 
> on,
> either?
> 
> 

pip runs egg_info because setuptools does not write out to PKG-INFO what
the dependencies are (it does write it out to a different text file though). 
But IIRC
that text file is not guaranteed to exist in the distribution. There's also the
history where pip was trying to preserve as much backwards compat with
easy_install as it could, and if you used the file that egg_info writes out
then you'll only get the requirements for the system that the distribution was
packaged on. Any if statements that affect the dependencies won't be
in effect.
> 
> Regards,
> 
> Vinay Sajip
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org (mailto:Python-Dev@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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Vinay Sajip]

Donald Stufft  gmail.com> writes:

> This is insane. A fairly simple database query is going to "grind the PyPI
> servers into dust"?  You're going to need to back up this FUD or please
> refrain from spouting it.

Never mind the "Obsoletes" information - even the more useful "Requires-Dist"
information is not exposed via PyPI, even though it appears to be stored in the
database. (Or if it is, please point me to where - I must have missed it.)

Even if this were to be made available, it's presumably obtained from PKG-INFO.
As I understand, this data is not considered reliable - for example, pip runs
egg_info on downloaded packages to get updated information when determining
dependencies to be downloaded. If the Requires-Dist info in PKG-INFO can't be
relied on, surely less critical information such as Obsoletes can't be relied 
on,
either?

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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Toshio Kuratomi]

On Wed, Dec 05, 2012 at 07:34:41PM -0500, PJ Eby wrote:
> On Wed, Dec 5, 2012 at 6:07 PM, Donald Stufft  wrote:
> 
> Nobody has actually proposed a better one, outside of package renaming
> -- and that example featured an author who could just as easily have
> used an obsoleted-by field.
> 
How about pexpect and pextpect-u as a better example?

> 
> > Very convenient to declare that one of the major use cases for
> > Obsoletes over Obsoleted-By is not valid because of your own
> > personal opinions.
> 
> I didn't say it was invalid, I said:
> 
> """Note that "the author of package X no longer maintains it" does not
> equal "package Y is entitled to name itself the successor and enforce
> this upon all users"""
> 
> These things are not equal.  AFAIK, well-managed Linux distros do not
> allow random forkers to declare themselves the official successor to a
> defunct package, so any analogy between this use case in the Python
> world and the distro world is strained at *best*.
> 
Note that although well-managed Linux distros attempt to control random
forking internally, the distro package managers don't prevent people from
installing from third parties.  So Ubuntu PPAs, upstreams that provide their
own rpms/debs, and major third party repos (for instance, rpmfusion as
an add-on repo to Fedora) all have and sometimes (mis)use the ability to
Obsolete packages in the base repository.

So Donald isn't stretching the relationship quite as far as you make it out.
The ecosystem of packages for a distro carries uncontrolled packages just as
much as pypi.

> 
> > and merely having the ability to use it when it is the best tool for the job
> > isn't going to cause any great issue.
> 
> One of the posts I linked presents an instance where it would have
> actually *harmed* things to specify it, and it's quite easy to see how
> the same problem would arise if used for non-file-related conflicts...
> 
> And the problem present is *directly* tied to the lack of a
> third-party Z who decides whether X and Y, as configured for release Q
> of distro P, "conflict".
> 
> This is not a problem that is solvable even in *principle* for an
> automated tool in the absence of party Z, which means that any such
> field's actual function is limited to a heads-up to a human user.
> 
And the same for Provides. (ie: latest foo is 0.6c; bar Provides: foo-0.6d.
an automated tool that finds both foo and bar in its dep tree can choose to
install bar and not foo.)

The ability for this class of fields to cause harm is not, to me,
a compelling argument not to include them.  It could be an argument to
explicitly tell implementers of install tools that they all have caveats
when used with pypi and similar unpoliced community package repositories.
The install tools can then choose how they wish to deal with those caveats.
Some example strategies: choose to prompt the user as to which to install,
choose to always treat the fields as human-informational only, mark some
repositories as being trusted to contain packages where these fields are
active and other repositories where the fields are ignored.

-Toshio



pgpIdSsnfDzFy.pgp
Description: PGP signature
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Nick Coghlan]

On Thu, Dec 6, 2012 at 2:54 PM, Nick Coghlan  wrote:

> On Thu, Dec 6, 2012 at 1:12 PM, Daniel Holth  wrote:
>
>> Makes sense. How about calling it Replacement. 0 or 1?
>>
>
> Hah, you'd think I'd have learned by now to finish reading a thread before
> replying. It will be nice to get this addressed along with the other
> changes :)
>
> (FWIW, Conflicts and Obsoletes are messy in RPM as well, and especially
> troublesome as soon as you start enabling multiple upstream repos from
> different providers. The metadata problem is handled by prebuilding indices
> when the repo changes, but that's still more work for the server, and more
> work for clients)
>
>
>> Replacement (optional)
>> ::
>>
>
>
> I like verb forms like Obsoleted-By or Replaced-By, as the noun form is
> ambiguous about the direction of the change. Since the field being replaced
> is Obsoletes, Obsoleted-By makes sense.
>

Although Replaced-By would be fine as well - it's certainly much easier to
say than the mouthful that is Obsoleted-By.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Nick Coghlan]

On Thu, Dec 6, 2012 at 1:12 PM, Daniel Holth  wrote:

> Makes sense. How about calling it Replacement. 0 or 1?
>

Hah, you'd think I'd have learned by now to finish reading a thread before
replying. It will be nice to get this addressed along with the other
changes :)

(FWIW, Conflicts and Obsoletes are messy in RPM as well, and especially
troublesome as soon as you start enabling multiple upstream repos from
different providers. The metadata problem is handled by prebuilding indices
when the repo changes, but that's still more work for the server, and more
work for clients)


> Replacement (optional)
> ::
>


I like verb forms like Obsoleted-By or Replaced-By, as the noun form is
ambiguous about the direction of the change. Since the field being replaced
is Obsoletes, Obsoleted-By makes sense.


>
> Indicates that this project is no longer being developed.  The named
> project provides a drop-in replacement.
>

Typically, the new version *won't* be a drop-in replacement (e.g. you'll
likely at least have to import from a different top level package).
Instead, the field would more often be used as an explicit indicator that
the project is no longer receiving updates, as the *development team* has
moved on, so users may want to consider either migrating, taking over
development (if the former developers are amenable) or forking.

If the replacing project *is* a drop-in replacement for the old project,
then it should also advertise a Provides-Dist for the original project.
Automated tools can then easily detect the two cases:

A Obsoleted-By-Dist B and B Provides-Dist A = A is defunct, and B should be
a drop-in replacement for A
A Obsoleted-By-Dist B (without a Provides-Dist on B) = A is defunct, B is a
replacement for A, but some porting will be needed

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Terry Reedy]

On 12/5/2012 10:12 PM, Daniel Holth wrote:

Makes sense. How about calling it Replacement. 0 or 1?

Replacement (optional)
::

Indicates that this project is no longer being developed.  The named
project provides a drop-in replacement.

A version declaration may be supplied and must follow the rules described
in `Version Specifiers`_.

The most common use of this field will be in case a project name changes.

Examples::

 Name: BadName
 Replacement: AcceptableName

 Replacement: AcceptableName (>=4.0.0)


I like it. 'Replacement' is broader in meaning, more neutral, and less 
awkward than 'Obsoleted-by'. And I agree that A users have much more 
need to know about B the vice-versa. It is much the same situation with 
Py 2 and Py 3 (although the latter is *not* a drop-in replacement).


--
Terry Jan Reedy

___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Nick Coghlan]

On Thu, Dec 6, 2012 at 8:30 AM, Daniel Holth  wrote:

> My desire is to invent the useful "wheel" binary package format in a
> reasonable and limited amount of time by making changes to Metadata 1.2 and
> implementing the new metadata format and wheel in distribute and pip. Help
> me out by allowing useless but un-changed fields to remain in this version
> of the PEP. I am done with the PEP and submit that it is not worse than its
> predecessor.
>

Agreed. PJE's arguments sound reasonable (especially since Obsoletes
doesn't get used much in RPM-land either - Provides & Conflicts are both
far more common), but they're orthogonal to the current aims of the
metadata 1.3 update. If another author wanted to create a subsequent 1.4
update that was focused on replacing Obsoletes with Obsoleted-By, that
would be fine (alternatively, a patch to the current PEP draft may be
acceptable, but accepting such a change would be up to Daniel as the PEP
author).


>
> I can participate in a discussion about any of the following:
> Summary of Differences From PEP 345
>
>- Metadata-Version is now 1.3.
>- Values are now expected to be UTF-8.
>- A payload (containing the description) may appear after the headers.
>- Added extra to environment markers.
>- Most fields are now optional.
>- Changed fields:
>   - Description
>   - Project-URL
>   - Requires-Dist
>- Added fields:
>   - Extension
>   - Provides-Extra
>   - Setup-Requires-Dist
>
>
> ___
> 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/ncoghlan%40gmail.com
>
>


-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Daniel Holth]

Makes sense. How about calling it Replacement. 0 or 1?

Replacement (optional)
::

Indicates that this project is no longer being developed.  The named
project provides a drop-in replacement.

A version declaration may be supplied and must follow the rules described
in `Version Specifiers`_.

The most common use of this field will be in case a project name changes.

Examples::

Name: BadName
Replacement: AcceptableName

Replacement: AcceptableName (>=4.0.0)
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[MRAB]

On 2012-12-06 02:12, Stephen J. Turnbull wrote:

I understand the PEP author's frustration with continued discussion,
but I think this subthread on Obsoletes vs. Obsoleted-By is not mere
bikeshedding on names.  It matters *which package* presents the
information.


Donald Stufft writes:
  > On Wednesday, December 5, 2012 at 6:18 PM, Barry Warsaw wrote:
  > > On Dec 05, 2012, at 06:07 PM, Donald Stufft wrote:
  > >
  > > > If you're installing B you've prescribed trust to that
  > > > author. If you don't trust the author then why are you
  > > > installing (and then executing) code they wrote.

The author may be a genius when it comes to writing code, and an idiot
when it comes to distributing it.  Distribution is much harder than it
looks, as you know.  Trusting the author's *content* and trusting the
author's *metadata* are not equivalent!

As far as I can see, the semantics of putting "Obsoletes: A" into B
without changing A are the same as the semantics of putting "Provides:
A" into B (without changing A).[1]  Only if A includes "Obsoleted-By: B"
can a user be confident that B is a true successor to A.

Furthermore, as has been pointed out, the presence of "Obsoleted-By"
in A has the huge advantage of informing users and developers of
dependent packages alike that A is obsolete when they try to update A.
If A is not changed, then an attempted update will tell them exactly
that, and they may never find out about B.  But if A is modified in
this trivial way, the package system can automatically inform them.
This is also trivial, requiring no database queries.

"Simple is better than complex."


That makes sense.

In summary, someone using B won't care that it has replaced A, but
someone using A needs to be told that it has been replaced by B.
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Stephen J. Turnbull]

I understand the PEP author's frustration with continued discussion,
but I think this subthread on Obsoletes vs. Obsoleted-By is not mere
bikeshedding on names.  It matters *which package* presents the
information.


Donald Stufft writes:
 > On Wednesday, December 5, 2012 at 6:18 PM, Barry Warsaw wrote:
 > > On Dec 05, 2012, at 06:07 PM, Donald Stufft wrote:
 > > 
 > > > If you're installing B you've prescribed trust to that
 > > > author. If you don't trust the author then why are you
 > > > installing (and then executing) code they wrote.

The author may be a genius when it comes to writing code, and an idiot
when it comes to distributing it.  Distribution is much harder than it
looks, as you know.  Trusting the author's *content* and trusting the
author's *metadata* are not equivalent!

As far as I can see, the semantics of putting "Obsoletes: A" into B
without changing A are the same as the semantics of putting "Provides:
A" into B (without changing A).[1]  Only if A includes "Obsoleted-By: B"
can a user be confident that B is a true successor to A.

Furthermore, as has been pointed out, the presence of "Obsoleted-By"
in A has the huge advantage of informing users and developers of
dependent packages alike that A is obsolete when they try to update A.
If A is not changed, then an attempted update will tell them exactly
that, and they may never find out about B.  But if A is modified in
this trivial way, the package system can automatically inform them.
This is also trivial, requiring no database queries.

"Simple is better than complex."




Footnotes: 
[1]  A trustworthy author of B wouldn't use "Provides" unless he
thought B was indeed a drop-in, and presumbly superior, replacement
for A.  And that's all that "Obsoletes" can tell you!


___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

On Wed, Dec 5, 2012 at 6:07 PM, Donald Stufft  wrote:
> Arguing over Obsoletes vs Renames is a massive bikeshedding argument.

And is entirely beside the point.  The substantive question is whether
it's Obsoletes or Obsoleted-By - i.e., which side is it declared on.

> So it's a bad example. Hardly an argument against it.

Nobody has actually proposed a better one, outside of package renaming
-- and that example featured an author who could just as easily have
used an obsoleted-by field.


> Will require support from PyPI but this ultimately isn't a big deal.

...and every PyPI clone.  And of course the performance issues.


> If you're installing B you've prescribed trust to that author. If you don't
> trust the author then why are you installing (and then executing) code
> they wrote.

Trusting their code is one thing; trusting whether they understood a
PEP (and its interactions with various installation tools) well enough
to not accidentally delete *somebody else's code* out of my system is
another thing altogether.

OTOH, trusting an author to tell me (in an automated fashion), "hey,
you should switch to this other thing as soon as you can" is a FAR
smaller amount of required trust.

Arguing that because I have to trust one thing, means I must trust
another, is a "Fallacy of Gray" argument.


> Very convenient to declare that one of the major use cases for
> Obsoletes over Obsoleted-By is not valid because of your own
> personal opinions.

I didn't say it was invalid, I said:

"""Note that "the author of package X no longer maintains it" does not
equal "package Y is entitled to name itself the successor and enforce
this upon all users"""

These things are not equal.  AFAIK, well-managed Linux distros do not
allow random forkers to declare themselves the official successor to a
defunct package, so any analogy between this use case in the Python
world and the distro world is strained at *best*.


> Unless you think there are
> no cases where two packages can conflict in more than what files
> are going to be installed

The rationale for that is laid out in the posts I linked.

> then there are cases where it would be helpful

Please, present a *real-life instance* where it would have been helpful to you.

> and merely having the ability to use it when it is the best tool for the job
> isn't going to cause any great issue.

One of the posts I linked presents an instance where it would have
actually *harmed* things to specify it, and it's quite easy to see how
the same problem would arise if used for non-file-related conflicts...

And the problem present is *directly* tied to the lack of a
third-party Z who decides whether X and Y, as configured for release Q
of distro P, "conflict".

This is not a problem that is solvable even in *principle* for an
automated tool in the absence of party Z, which means that any such
field's actual function is limited to a heads-up to a human user.


> This is insane. A fairly simple database query is going to "grind the PyPI
> servers into dust"?  You're going to need to back up this FUD or please
> refrain from spouting it.

I take it you're not familiar with PyPI's history of performance and
scaling problems over the last several years, then.  The statically
cached "/simple" index was developed precisely to stop *today's* class
of installation tools from killing the servers...  and then mirroring
PyPI was still required to scale.  Any proposal that calls for
encouraging tools to query a metadata field *every time* a package is
installed (or even just downloaded) almost certainly needs to be
vetted with the PyPI admin team.
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

On Wed, Dec 5, 2012 at 5:30 PM, Daniel Holth  wrote:
> My desire is to invent the useful "wheel" binary package format in a
> reasonable and limited amount of time by making changes to Metadata 1.2 and
> implementing the new metadata format and wheel in distribute and pip. Help
> me out by allowing useless but un-changed fields to remain in this version
> of the PEP. I am done with the PEP and submit that it is not worse than its
> predecessor.

You could just mark those fields as deprecated and that they should
not be used to delete packages or block packages from installation.

Justification: nobody has managed to make them work in an automated
tool yet, and their use in same is controversial, so they are
downgraded to human-informational only.

Please, let's not have yet *another* metadata spec that advertises
these attractive nuisance[1] fields.  I do not want us to be having
this same conversation AGAIN the next time any metadata changes are
being considered.  We've already had it too many times already.  PEPs
are supposed to summarize these discussions for that very reason.

---
[1] For non-native speakers, an attractive nuisance is a dangerous
thing that entices unsuspecting persons to play with it;
http://en.wikipedia.org/wiki/Attractive_nuisance_doctrine has more
details.
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Donald Stufft]

On Wednesday, December 5, 2012 at 6:18 PM, Barry Warsaw wrote:
> On Dec 05, 2012, at 06:07 PM, Donald Stufft wrote:
> 
> > If you're installing B you've prescribed trust to that author. If you don't
> > trust the author then why are you installing (and then executing) code
> > they wrote. 
> > 
> 
> 
> What you installed Z, but B got installed because it was a dependency three
> levels down?
> 
> 

Sure, you granted trust to Z, Z granted trust to Y, and Y granted trust to B. 
Like
in SSL certificates there was a chain of trust. If you don't trust Z then don't 
install
their package. 
> 
> > Very convenient to declare that one of the major use cases for
> > Obsoletes over Obsoleted-By is not valid because of your own
> > personal opinions. Like I said above, if you're installing a package
> > that someone has uploaded you've implicitly granted them trust. There
> > is far worse things that a bad Python citizen can do during, and after
> > and install that what is allowed by Obsoletes.
> > 
> 
> 
> Well, basically never installing anything from PyPI except into a virtualenv
> is probably a good recommendation (maybe even now).
> 
> 

A virtualenv only protects you from well behaved packages. There is no way
to prevent a package author from doing very nasty things to you if they wish.
Providing more power in the metadata doesn't make this situation better or
worse, it just makes more standard paths in the cases where you do need
to do it.
> 
> > End systems often times do not have a singular organization controlling
> > every package in their system. The best example is Ubuntu and their PPA's. 
> > 
> 
> 
> Well, PPAs are awesome, but have known and well-publicized trust issues. I
> wouldn't enable a PPA into my running system without really knowing who the
> owner is and why I'm using their PPA. Or doing a lot of testing in a chroot
> first, and probably pinning the package set to just the one(s) from the PPA I
> care about.
> 
> 

Basically the same thing can be said about packages on PyPI. All the same
trust issues exist there. Simply installing a Python package is already granting
far more trust than Obsoletes requires since installing a package is executed
someone else's python code on your system. Even if you remove setup.py you're
still going to be executing their code on your system. If you do not trust the
author of the packages you are installing, you do not install their packages.

___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Barry Warsaw]

On Dec 05, 2012, at 06:07 PM, Donald Stufft wrote:

>If you're installing B you've prescribed trust to that author. If you don't
>trust the author then why are you installing (and then executing) code
>they wrote. 

What you installed Z, but B got installed because it was a dependency three
levels down?

>Very convenient to declare that one of the major use cases for
>Obsoletes over Obsoleted-By is not valid because of your own
>personal opinions. Like I said above, if you're installing a package
>that someone has uploaded you've implicitly granted them trust. There
>is far worse things that a bad Python citizen can do during, and after
>and install that what is allowed by Obsoletes.

Well, basically never installing anything from PyPI except into a virtualenv
is probably a good recommendation (maybe even now).

>End systems often times do not have a singular organization controlling
>every package in their system. The best example is Ubuntu and their PPA's. 

Well, PPAs are awesome, but have known and well-publicized trust issues.  I
wouldn't enable a PPA into my running system without really knowing who the
owner is and why I'm using their PPA.  Or doing a lot of testing in a chroot
first, and probably pinning the package set to just the one(s) from the PPA I
care about.

Cheers,
-Barry
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Barry Warsaw]

On Dec 05, 2012, at 04:10 PM, PJ Eby wrote:

>While it's certainly desirable to not invent wheels, it's important to
>understand that the Python community does not work the same way as a
>Linux distribution.  We are not a single organization shipping a
>fully-functional and configured machine, we are hundreds of individual
>authors shipping our own stuff.  Conflict resolution and package
>replacement (and even deciding what it is that things "provide" or
>"require") are primarily *human* processes, not technical ones.
>Relationship and support "contracts", IOW, rather than software
>contracts.
>
>That's why, in the distro world, a package manager can use simple
>fields to carry out the will of the human organization that made those
>support and compatibility decisions.  For Python, the situation is a
>bit more complicated, which is why clear thinking is needed.  Simply
>copying fields blindly from other packaging systems just isn't going
>to cut it.

+1

>Now, if the will of the community is to turn PyPI into a distro-style
>repository, that's fine...

Please no!  -1 :)

-Barry
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Donald Stufft]

On Wednesday, December 5, 2012 at 4:10 PM, PJ Eby wrote:
> My point is that this can only work if the "obsoleting" is effectively
> just a rename, in which case the field should be "renames", or better
> still, "renamed-to" on the originating package.

Arguing over Obsoletes vs Renames is a massive bikeshedding argument. 
> As I've mentioned repeatedly, Obsoleted-By handles more use cases than
> Obsoletes, and has at least one practical automated use case
> (notifying a developer that their project is depending on something
> that's obsolete).
> 
> Also, the example given as a use case in the PEP (Gorgon to Torqued)
> is not just wrong, it's *actively misleading*. Gorgon and Torqued are
> transparent renames of Medusa and Twisted, which do not share a common
> API and thus cannot be used as the subject of any automated processing
> (in the case of Obsoletes) without doing some kind of PyPI metadata
> search for every package installed every time a package is installed.
> 
> 

So it's a bad example. Hardly an argument against it.
> 1. It cannot be used to prevent the installation of an obsolete
> package without a PyPI metadata search, since you must examine every
> *other* package on PyPI to find out whether some package obsoletes the
> one you're trying to install.
> 
> 

Will require support from PyPI but this ultimately isn't a big deal. 
> 
> 2. Unlike RPM, where metadata is provided by a trusted third party,
> Obsoletes can be specified by any random forker (no pun intended),
> which makes this information a mere advertisement... and an
> advertisement to the wrong audience at that, because they must have
> *already* found B in order to discover that it replaces A!
> 
> 

If you're installing B you've prescribed trust to that author. If you don't
trust the author then why are you installing (and then executing) code
they wrote. 
> 
> 3. Nobody has yet supplied a use case where Obsoletes would not be
> strictly improved upon by Obsoleted-By. (Note that "the author of
> package X no longer maintains it" does not equal "package Y is
> entitled to name itself the successor and enforce this upon all users"
> -- this can work in RPM only because it is a third party Z who
> declares Y the successor to X, and there is no such party Z in the
> Python world.)
> 
> 

Very convenient to declare that one of the major use cases for
Obsoletes over Obsoleted-By is not valid because of your own
personal opinions. Like I said above, if you're installing a package
that someone has uploaded you've implicitly granted them trust. There
is far worse things that a bad Python citizen can do during, and after
and install that what is allowed by Obsoletes.
> 
> 
> > I don't see this in this thread, could you link it again?
> 
> http://mail.python.org/pipermail/catalog-sig/2010-October/003368.html
> http://mail.python.org/pipermail/catalog-sig/2010-October/003364.html
> 
> These posts also address why a "Conflicts" field is *also* unlikely to
> be particularly useful in practice, in part for reasons that relate to
> differences between RPM-land and Python-land. (For example, RPMs can
> conflict over things besides files, due to runtime and configuration
> issues that are out-of-scope for a Python installer tool.)
> 
> 

I don't think Conflicts is something that every single package is going
to require. As you said the tools themselves are going to handle the
obvious cases for the bulk of situations. Unless you think there are
no cases where two packages can conflict in more than what files
are going to be installed then there are cases where it would be helpful
and merely having the ability to use it when it is the best tool for the job
isn't going to cause any great issue. 
> 
> While it's certainly desirable to not invent wheels, it's important to
> understand that the Python community does not work the same way as a
> Linux distribution. We are not a single organization shipping a
> fully-functional and configured machine, we are hundreds of individual
> authors shipping our own stuff. Conflict resolution and package
> replacement (and even deciding what it is that things "provide" or
> "require") are primarily *human* processes, not technical ones.
> Relationship and support "contracts", IOW, rather than software
> contracts.
> 
> 

End systems often times do not have a singular organization controlling
every package in their system. The best example is Ubuntu and their PPA's. 
> 
> Now, if the will of the community is to turn PyPI into a distro-style
> repository, that's fine... but even if you completely ignore the human
> issues, there are still technical ones. Generally, distro-style
> repositories work by downloading the full metadata set (or at least an
> index) to a user's machine. And that's the sort of architecture you'd
> need in order for these type of fields to be technically feasible
> (e.g., doing an index search for Obsoletes), without grinding the PyPI
> servers into dust.

This is insane. A fairly simple dat

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Daniel Holth]

On Wed, Dec 5, 2012 at 4:10 PM, PJ Eby  wrote:

> On Wed, Dec 5, 2012 at 2:46 AM, Donald Stufft 
> wrote:
> > There's nothing preventing an installer from, during it's attempt to
> > install B, see it Obsoletes A, looking at what depends on A and
> > warning the user what is going to happen and prompt it.
>
> Unless the user wrote those things that depend on A, they aren't going
> to be in a position to do anything about it.  (Contrast with a distro,
> where dependencies are indirect - the other package will depend on an
> abstraction provided by both A and B, rather than directly depending
> on A *or* B.)
>
> (Also note that all the user knows at this point is that the author of
> B *claims* to obsolete A, not that the authority managing the
> repository as a whole has decreed B to obsolete A.)
>
>
> > You can automatically uninstall A from B in an automatic dependency
> management system
>
> My point is that this can only work if the "obsoleting" is effectively
> just a rename, in which case the field should be "renames", or better
> still, "renamed-to" on the originating package.
>
> As I've mentioned repeatedly, Obsoleted-By handles more use cases than
> Obsoletes, and has at least one practical automated use case
> (notifying a developer that their project is depending on something
> that's obsolete).
>
> Also, the example given as a use case in the PEP (Gorgon to Torqued)
> is not just wrong, it's *actively misleading*.  Gorgon and Torqued are
> transparent renames of Medusa and Twisted, which do not share a common
> API and thus cannot be used as the subject of any automated processing
> (in the case of Obsoletes) without doing some kind of PyPI metadata
> search for every package installed every time a package is installed.
>
>
> > I think Obsoletes as is an alright bit of information.
>
> 1. It cannot be used to prevent the installation of an obsolete
> package without a PyPI metadata search, since you must examine every
> *other* package on PyPI to find out whether some package obsoletes the
> one you're trying to install.
>
> 2. Unlike RPM, where metadata is provided by a trusted third party,
> Obsoletes can be specified by any random forker (no pun intended),
> which makes this information a mere advertisement... and an
> advertisement to the wrong audience at that, because they must have
> *already* found B in order to discover that it replaces A!
>
> 3. Nobody has yet supplied a use case where Obsoletes would not be
> strictly improved upon by Obsoleted-By.  (Note that "the author of
> package X no longer maintains it" does not equal "package Y is
> entitled to name itself the successor and enforce this upon all users"
> -- this can work in RPM only because it is a third party Z who
> declares Y the successor to X, and there is no such party Z in the
> Python world.)
>
>
> > I don't see this in this thread, could you link it again?
>
> http://mail.python.org/pipermail/catalog-sig/2010-October/003368.html
> http://mail.python.org/pipermail/catalog-sig/2010-October/003364.html
>
> These posts also address why a "Conflicts" field is *also* unlikely to
> be particularly useful in practice, in part for reasons that relate to
> differences between RPM-land and Python-land.  (For example, RPMs can
> conflict over things besides files, due to runtime and configuration
> issues that are out-of-scope for a Python installer tool.)
>
> While it's certainly desirable to not invent wheels, it's important to
>

My desire is to invent the useful "wheel" binary package format in a
reasonable and limited amount of time by making changes to Metadata 1.2 and
implementing the new metadata format and wheel in distribute and pip. Help
me out by allowing useless but un-changed fields to remain in this version
of the PEP. I am done with the PEP and submit that it is not worse than its
predecessor.

I can participate in a discussion about any of the following:
Summary of Differences From PEP 345

   - Metadata-Version is now 1.3.
   - Values are now expected to be UTF-8.
   - A payload (containing the description) may appear after the headers.
   - Added extra to environment markers.
   - Most fields are now optional.
   - Changed fields:
  - Description
  - Project-URL
  - Requires-Dist
   - Added fields:
  - Extension
  - Provides-Extra
  - Setup-Requires-Dist
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

On Wed, Dec 5, 2012 at 2:46 AM, Donald Stufft  wrote:
> There's nothing preventing an installer from, during it's attempt to
> install B, see it Obsoletes A, looking at what depends on A and
> warning the user what is going to happen and prompt it.

Unless the user wrote those things that depend on A, they aren't going
to be in a position to do anything about it.  (Contrast with a distro,
where dependencies are indirect - the other package will depend on an
abstraction provided by both A and B, rather than directly depending
on A *or* B.)

(Also note that all the user knows at this point is that the author of
B *claims* to obsolete A, not that the authority managing the
repository as a whole has decreed B to obsolete A.)


> You can automatically uninstall A from B in an automatic dependency
management system

My point is that this can only work if the "obsoleting" is effectively
just a rename, in which case the field should be "renames", or better
still, "renamed-to" on the originating package.

As I've mentioned repeatedly, Obsoleted-By handles more use cases than
Obsoletes, and has at least one practical automated use case
(notifying a developer that their project is depending on something
that's obsolete).

Also, the example given as a use case in the PEP (Gorgon to Torqued)
is not just wrong, it's *actively misleading*.  Gorgon and Torqued are
transparent renames of Medusa and Twisted, which do not share a common
API and thus cannot be used as the subject of any automated processing
(in the case of Obsoletes) without doing some kind of PyPI metadata
search for every package installed every time a package is installed.


> I think Obsoletes as is an alright bit of information.

1. It cannot be used to prevent the installation of an obsolete
package without a PyPI metadata search, since you must examine every
*other* package on PyPI to find out whether some package obsoletes the
one you're trying to install.

2. Unlike RPM, where metadata is provided by a trusted third party,
Obsoletes can be specified by any random forker (no pun intended),
which makes this information a mere advertisement... and an
advertisement to the wrong audience at that, because they must have
*already* found B in order to discover that it replaces A!

3. Nobody has yet supplied a use case where Obsoletes would not be
strictly improved upon by Obsoleted-By.  (Note that "the author of
package X no longer maintains it" does not equal "package Y is
entitled to name itself the successor and enforce this upon all users"
-- this can work in RPM only because it is a third party Z who
declares Y the successor to X, and there is no such party Z in the
Python world.)


> I don't see this in this thread, could you link it again?

http://mail.python.org/pipermail/catalog-sig/2010-October/003368.html
http://mail.python.org/pipermail/catalog-sig/2010-October/003364.html

These posts also address why a "Conflicts" field is *also* unlikely to
be particularly useful in practice, in part for reasons that relate to
differences between RPM-land and Python-land.  (For example, RPMs can
conflict over things besides files, due to runtime and configuration
issues that are out-of-scope for a Python installer tool.)

While it's certainly desirable to not invent wheels, it's important to
understand that the Python community does not work the same way as a
Linux distribution.  We are not a single organization shipping a
fully-functional and configured machine, we are hundreds of individual
authors shipping our own stuff.  Conflict resolution and package
replacement (and even deciding what it is that things "provide" or
"require") are primarily *human* processes, not technical ones.
Relationship and support "contracts", IOW, rather than software
contracts.

That's why, in the distro world, a package manager can use simple
fields to carry out the will of the human organization that made those
support and compatibility decisions.  For Python, the situation is a
bit more complicated, which is why clear thinking is needed.  Simply
copying fields blindly from other packaging systems just isn't going
to cut it.

Now, if the will of the community is to turn PyPI into a distro-style
repository, that's fine... but even if you completely ignore the human
issues, there are still technical ones.  Generally, distro-style
repositories work by downloading the full metadata set (or at least an
index) to a user's machine.  And that's the sort of architecture you'd
need in order for these type of fields to be technically feasible
(e.g., doing an index search for Obsoletes), without grinding the PyPI
servers into dust.
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Toshio Kuratomi]

On Wed, Dec 05, 2012 at 02:46:11AM -0500, Donald Stufft wrote:
> On Wednesday, December 5, 2012 at 2:13 AM, PJ Eby wrote:
> 
> On Mon, Dec 3, 2012 at 2:43 PM, Daniel Holth  wrote:
> 
> How to use Obsoletes:
> 
> The author of B decides A is obsolete.
> 
> A releases an empty version of itself that Requires: B
> 
> B Obsoletes: A
> 
> The package manager says "These packages are obsolete: A". Would you
> like to
> remove them?
> 
> User says "OK".
> 
> 
> Um, no. Even if the the author of A and B are the same person, you
> can't remove A if there are other things on the user's system using
> it. The above scenario does not work *at all*, ever, except in the
> case where B is simply an updated version of A (i.e. identical API) --
> in which case, why bother? To change the project name? (Then it
> should be "Formerly-named" or something like that, not "Obsoletes".)
> 
> You can automatically uninstall A from B in an automatic dependency
> management system.  I *think* RPM does this, at the very least

This is correct.

> I believe it refuses to install B if A is already there (and the reverse
> as well).*

I'd have to test this but I believe you are correct about the first.  Not
sure about the reverse.

> There's nothing preventing an installer from, during it's attempt to
> install B, see it Obsoletes A, looking at what depends on A and
> warning the user what is going to happen and prompt it.
> 
In rpm-land, if something depended on A and nothing besides the actual
A package provided A, rpm will refuse to install B.  But rpm is meant to be
used unattended so different package managers could certainly choose to
prompt.  For package renames, package B would have both an Obsoletes: A <=
$OLD_VERSION and a Provides: A = NEW_VERSION

-Toshio


pgptWKkjHQPiB.pgp
Description: PGP signature
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Donald Stufft]

On Wednesday, December 5, 2012 at 2:13 AM, PJ Eby wrote:
> On Mon, Dec 3, 2012 at 2:43 PM, Daniel Holth  (mailto:dho...@gmail.com)> wrote:
> > How to use Obsoletes:
> > 
> > The author of B decides A is obsolete.
> > 
> > A releases an empty version of itself that Requires: B
> > 
> > B Obsoletes: A
> > 
> > The package manager says "These packages are obsolete: A". Would you like to
> > remove them?
> > 
> > User says "OK".
> 
> Um, no. Even if the the author of A and B are the same person, you
> can't remove A if there are other things on the user's system using
> it. The above scenario does not work *at all*, ever, except in the
> case where B is simply an updated version of A (i.e. identical API) --
> in which case, why bother? To change the project name? (Then it
> should be "Formerly-named" or something like that, not "Obsoletes".)
> 
> 

You can automatically uninstall A from B in an automatic dependency
management system. I *think* RPM does this, at the very least
I believe it refuses to install B if A is already there (and the reverse
as well).*

There's nothing preventing an installer from, during it's attempt to
install B, see it Obsoletes A, looking at what depends on A and
warning the user what is going to happen and prompt it.

I think Obsoletes as is an alright bit of information. I think the biggest
flaw with Obsoletes isn't in Obsoletes itself, but is in the lack of a
Conflicts tag that has the same functionality (minimally refusal to
install both, possibly uninstall the previous one with a prompt to the
user).

Obsoletes has the semantics of a logical successor (typically renames)
while Conflicts should have the semantics of a competitor.

distribute would conflict with setuptools, foo2 would Obsoletes foo.

* I could be wrong about RPM's treatment of Obsoletes

 
> 
> Please, *please* see the previous Catalog-SIG discussion I linked:
> this is only one of multiple metadata fields that were thoroughly
> debunked in that discussion as completely useless for automated
> dependency management.
> 
> 

I don't see this in this thread, could you link it again? 
> ___
> Python-Dev mailing list
> Python-Dev@python.org (mailto:Python-Dev@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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

On Mon, Dec 3, 2012 at 2:43 PM, Daniel Holth  wrote:
> How to use Obsoletes:
>
> The author of B decides A is obsolete.
>
> A releases an empty version of itself that Requires: B
>
> B Obsoletes: A
>
> The package manager says "These packages are obsolete: A". Would you like to
> remove them?
>
> User says "OK".
>

Um, no.  Even if the the author of A and B are the same person, you
can't remove A if there are other things on the user's system using
it.  The above scenario does not work *at all*, ever, except in the
case where B is simply an updated version of A (i.e. identical API) --
in which case, why bother?  To change the project name?  (Then it
should be "Formerly-named" or something like that, not "Obsoletes".)

Please, *please* see the previous Catalog-SIG discussion I linked:
this is only one of multiple metadata fields that were thoroughly
debunked in that discussion as completely useless for automated
dependency management.
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Daniel Holth]

How to use Obsoletes:

The author of B decides A is obsolete.

A releases an empty version of itself that Requires: B

B Obsoletes: A

The package manager says "These packages are obsolete: A". Would you like
to remove them?

User says "OK".


On Wed, Nov 21, 2012 at 2:54 AM, Stephen J. Turnbull wrote:

> PJ Eby writes:
>  > On Wed, Nov 21, 2012 at 12:00 AM, Stephen J. Turnbull <
> step...@xemacs.org>wrote:
>
>  > > What I care about is when I'm using Gorgon, and there's something
>  > > "better" (or worse, "correct") to use in my application.
>  >
>  > Hence my suggestion for an Obsoleted-By field, in which Gorgon would be
>  > able to suggest alternatives.
>
> My bad, my precise intention was to follow up on your idea (which,
> credit where credit is due, I had *not* hit upon independently).  I
> should have made that clear.
>
> (I really shouldn't be answering English email at a Japanese-speaking
> conference, my brain thinks it knows what it's doing but shirazuni 日
> 本文化が染み込む)
>
>  > > It might be a good idea to have a just-like-Amazon
>  > >
>  > > While-This-Package-Is-Great-You-Might-Also-Consider:
>  > >
>  > > field.
>  >
>  > Yeah, that's basically what Obsoleted-By is for.
>
> Well, Obsoleted-By is pretty strong language for suggesting possible
> alternatives.  But I suspect that few projects would really want to be
> suggesting competitors' products *or* their own oldie-but-still-goodie
> that they'd really like to obsolete ASAP (put an Obsoleted-By line in
> every Python 2 distribution, anyone? :-)
> ___
> 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/dholth%40gmail.com
>
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Stephen J. Turnbull]

PJ Eby writes:
 > On Wed, Nov 21, 2012 at 12:00 AM, Stephen J. Turnbull 
 > wrote:

 > > What I care about is when I'm using Gorgon, and there's something
 > > "better" (or worse, "correct") to use in my application.
 > 
 > Hence my suggestion for an Obsoleted-By field, in which Gorgon would be
 > able to suggest alternatives.

My bad, my precise intention was to follow up on your idea (which,
credit where credit is due, I had *not* hit upon independently).  I
should have made that clear.

(I really shouldn't be answering English email at a Japanese-speaking
conference, my brain thinks it knows what it's doing but shirazuni 日
本文化が染み込む)

 > > It might be a good idea to have a just-like-Amazon
 > >
 > > While-This-Package-Is-Great-You-Might-Also-Consider:
 > >
 > > field.
 > 
 > Yeah, that's basically what Obsoleted-By is for.

Well, Obsoleted-By is pretty strong language for suggesting possible
alternatives.  But I suspect that few projects would really want to be
suggesting competitors' products *or* their own oldie-but-still-goodie
that they'd really like to obsolete ASAP (put an Obsoleted-By line in
every Python 2 distribution, anyone? :-)
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

On Wed, Nov 21, 2012 at 12:00 AM, Stephen J. Turnbull wrote:

> Daniel Holth writes:
>
>  > When I used Obsoletes, it meant "I am no longer developing this other
>  > package that is identical to this re-named package".
>
> But as a user I could care less!  The authors may care, but I don't
> care if Torqued "obsoletes" Gorgon, because in using Torqued I'm
> DTRT'ing even though I don't know it.
>
> What I care about is when I'm using Gorgon, and there's something
> "better" (or worse, "correct") to use in my application.
>

Hence my suggestion for an Obsoleted-By field, in which Gorgon would be
able to suggest alternatives.



> It might be a good idea to have a just-like-Amazon
>
> While-This-Package-Is-Great-You-Might-Also-Consider:
>
> field.
>

Yeah, that's basically what Obsoleted-By is for.
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Stephen J. Turnbull]

Daniel Holth writes:

 > When I used Obsoletes, it meant "I am no longer developing this other
 > package that is identical to this re-named package".

But as a user I could care less!  The authors may care, but I don't
care if Torqued "obsoletes" Gorgon, because in using Torqued I'm
DTRT'ing even though I don't know it.

What I care about is when I'm using Gorgon, and there's something
"better" (or worse, "correct") to use in my application.

It might be a good idea to have a just-like-Amazon

While-This-Package-Is-Great-You-Might-Also-Consider:

field.

Tongue-in-cheeki-ly y'rs,
___
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

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Daniel Holth]

On Tue, Nov 20, 2012 at 7:18 PM, Jim Jewett  wrote:

> On 11/20/12, Daniel Holth  wrote:
> > On Tue, Nov 20, 2012 at 3:58 PM, Jim J. Jewett 
> > wrote:
>
> >> Vinay Sajip reworded the 'Provides-Dist' definition to explicitly say:
>
> >> > 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 ...
>
> >> (1)  Then how *should* the "bundle-of-several-components" case be
> >> represented?
>
> > The useful way to bundle a bunch of things would be to just include them
> > all in an executable folder or zipfile with __main__.py. PEP 426 and the
> > package database would not get involved. The bundle would be distributed
> as
> > an application you can download and use, not as an sdist on PyPI.
>
> When I look at, for example, twisted, there are some fairly fine
> distinctions.
>
> I can imagine some people wanting to handle each little piece
> differently, since that is the level at which they would be replaced
> by a more efficient implementation.  That doesn't mean that someone
> using the default should have to manage 47 separate little packages
> individually.
>
> Also note that ZODB is mentioned as a bundling example in the current
> (2012-11-14) PEP.  What does the PEP recommend that they do?  Stop
> including transaction?  Keep including it but stop 'Provides-Dist'-ing
> it?
>
> The current PEP also specifies that "This field must include the
> project identified in the Name field, followed by the version : Name
> (Version)." but the examples do not always include version.  Why is
> the MUST there?
>

ZODB is a bad example. The word "bundling" will be struck from the PEP
entirely. Two sdists should not be combined into one sdist when both
packages are still being developed.

If A and B are merged into a single PyPI package C, and A and B will no
longer be developed, then C may Provides-Dist A and B.

http://www.python.org/dev/peps/pep-0426/#requires-dist-multiple-use

No MUST on the Requires-Dist version. If no version is there, it should
satisfy any version requirement.

Is there some way to distinguish between concrete and abstract
> provisions?  For example, if  MyMail (2012.11.10)  includes
> 'Provides-Dist: email', does that really get parsed as 'Provides-Dist:
> email (2012.11.10)'?
>

No.

>> (2)  How is 'Provides-Dist' different from 'Obsoletes-Dist'?
>> The only difference I can see is that it may be a bit more polite
>> to people who do want to install multiple versions of a (possibly
>> abstract) package.

 > The intent of Provides and Obsoletes is different. Obsoletes would not
> > satisfy a requirement during dependency resolution.
>
> > The RPM guide explains a similar system:
>
> As best I can understand, Obsoletes means "Go ahead and uninstall that
> other package."
> Saying that *without* providing the same functionality seems like a
> sneaky spelling of "Please break whatever relies on that other
> package."
>
> I'm willing to believe that there is a more useful meaning.  I'm also
> willing to believe that they are logically redundant but express
> different intentions.  The current wording doesn't tell me which is
> true.  (Admittedly, that is arguably an upstream bug with other
> package systems, but you should still either fix it or explicitly
> delegate the definitions.)
>
> And as long as I'm asking for clarification, can foopkg-3.4 obsolete
> foopgk3.2?  If not, is it a semantics problem, or just not idiomatic?
> If so, does it have a precise meaning, such as "no longer
> interoperates with"?
>

When I used Obsoletes, it meant "I am no longer developing this other
package that is identical to this re-named package". The system of
requirements/conflicts (as the RPM system) does not appear to be entirely
orthogonal.

And now that I've looked more carefully ...
>
> Can a "Key: Value" pair be continued onto another line?  The syntax
> description under "Metadata Files" does not say so, but later text
> suggests that either leading whitespace or a leading tab specifically
> (from the example code) will work.  (And is description a special
> case?)
>

Description (now in the payload, please) is the only field that is commonly
multi-line.

Any field could continue onto the next line as far as the parser is
concerned. It probably would not make sense.

Is the payload assumed to be utf8 text?  Can it be itself a mime message?
>

The entire file needs to be utf-8. The payload is assumed to be utf-8 text
in this version. Wouldn't a mime message also be utf-8 text? (we wouldn't
know what to do with it)


> Are there any restrictions on 'Name'?  e.g., Can the name include
> spaces?  line breaks?  Must it be a valid python identifier?  A valid
> python qualname?
>

setuptools constrains it to alphanumeric characters. Metadata 1.3 doesn't
say.

'Version' says that it must be in the format specified in PEP 386.
> Unfortunately, it doesn't say which part of 386.  Do you mean t

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Jim Jewett]

On 11/20/12, Daniel Holth  wrote:
> On Tue, Nov 20, 2012 at 3:58 PM, Jim J. Jewett 
> wrote:

>> Vinay Sajip reworded the 'Provides-Dist' definition to explicitly say:

>> > 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 ...

>> (1)  Then how *should* the "bundle-of-several-components" case be
>> represented?

> The useful way to bundle a bunch of things would be to just include them
> all in an executable folder or zipfile with __main__.py. PEP 426 and the
> package database would not get involved. The bundle would be distributed as
> an application you can download and use, not as an sdist on PyPI.

When I look at, for example, twisted, there are some fairly fine distinctions.

I can imagine some people wanting to handle each little piece
differently, since that is the level at which they would be replaced
by a more efficient implementation.  That doesn't mean that someone
using the default should have to manage 47 separate little packages
individually.

Also note that ZODB is mentioned as a bundling example in the current
(2012-11-14) PEP.  What does the PEP recommend that they do?  Stop
including transaction?  Keep including it but stop 'Provides-Dist'-ing
it?

The current PEP also specifies that "This field must include the
project identified in the Name field, followed by the version : Name
(Version)." but the examples do not always include version.  Why is
the MUST there?

Is there some way to distinguish between concrete and abstract
provisions?  For example, if  MyMail (2012.11.10)  includes
'Provides-Dist: email', does that really get parsed as 'Provides-Dist:
email (2012.11.10)'?



>> (2)  How is 'Provides-Dist' different from 'Obsoletes-Dist'?
>> The only difference I can see is that it may be a bit more polite
>> to people who do want to install multiple versions of a (possibly
>> abstract) package.

> The intent of Provides and Obsoletes is different. Obsoletes would not
> satisfy a requirement during dependency resolution.

> The RPM guide explains a similar system:

As best I can understand, Obsoletes means "Go ahead and uninstall that
other package."
Saying that *without* providing the same functionality seems like a
sneaky spelling of "Please break whatever relies on that other
package."

I'm willing to believe that there is a more useful meaning.  I'm also
willing to believe that they are logically redundant but express
different intentions.  The current wording doesn't tell me which is
true.  (Admittedly, that is arguably an upstream bug with other
package systems, but you should still either fix it or explicitly
delegate the definitions.)

And as long as I'm asking for clarification, can foopkg-3.4 obsolete
foopgk3.2?  If not, is it a semantics problem, or just not idiomatic?
If so, does it have a precise meaning, such as "no longer
interoperates with"?

And now that I've looked more carefully ...

Can a "Key: Value" pair be continued onto another line?  The syntax
description under "Metadata Files" does not say so, but later text
suggests that either leading whitespace or a leading tab specifically
(from the example code) will work.  (And is description a special
case?)

Is the payload assumed to be utf8 text?  Can it be itself a mime message?

Are there any restrictions on 'Name'?  e.g., Can the name include
spaces?  line breaks?  Must it be a valid python identifier?  A valid
python qualname?

'Version' says that it must be in the format specified in PEP 386.
Unfortunately, it doesn't say which part of 386.  Do you mean that it
must be acceptable to verlib.NormalizedVersion without first having to
call suggest_normalized_version?

'Summary' specifies that it must be one line.  Is there a character
limit, or do you just mean "no line breaks"?  Do you want to add a
"Should be less than 80 characters" or some such, based on typical
tool presentation?  Would it be worth repeating the advice that longer
descriptions should go in the payload, after all headers?  (Otherwise,
they have to find 'Description' *and* notice that it is deprecated and
figure out what to do instead.)

Under 'Description', it isn't entirely clear whether what terminates
the field.  "Multiple paragraphs" suggests that there can be multiple
lines, but I'm guessing that -- in practice -- they have to be a
single logical line, with all but the first starting with whitespace.

Under 'Classifier', is PEP 301 really the current authority for
classifiers?  I would prefer at least a reference to
http://pypi.python.org/pypi?%3Aaction=list_classifiers demonstrating
which classifiers are currently meaningful.

Under 'Requires-Dist', there is an unclosed parenthesis.

Does the 'Setup-Requires-Dist' set implicitly include the
'Requires-Dist' set, or should a package be listed both ways if it is
required at both setup and runtime?

The Summary of Differences from PEP 345 mentions changes to
Requires-Dis

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Daniel Holth]

On Tue, Nov 20, 2012 at 3:58 PM, Jim J. Jewett  wrote:

>
>
> Vinay Sajip reworded the 'Provides-Dist' definition to explicitly say:
>
> > 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 ...
>
> (1)  Then how *should* the "bundle-of-several-components" case be
> represented?
>
> (2)  How is 'Provides-Dist' different from 'Obsoletes-Dist'?
> The only difference I can see is that it may be a bit more polite
> to people who do want to install multiple versions of a (possibly
> abstract) package.
>

The useful way to bundle a bunch of things would be to just include them
all in an executable folder or zipfile with __main__.py. PEP 426 and the
package database would not get involved. The bundle would be distributed as
an application you can download and use, not as an sdist on PyPI.

The intent of Provides and Obsoletes is different. Obsoletes would not
satisfy a requirement during dependency resolution.

The RPM guide explains a similar system:
This brings the total to four types of dependencies that the RPM system
tracks:

   - Requires, which tracks the capabilities a package requires
   - Provides, which tracks the capabilities a package provides for other
   packages
   - Conflicts, which describes the capabilities that if installed,
   conflict with capabilities in a package
   - Obsoletes, which describes the capabilities that this package will
   make obsolete

Packages advertise this dependency information. Each dependency holds the
type, such as requires, a capability, such as a shared library or a package
name, and optionally a version number, such as requiring the python package
at a version number greater than or equal to 2.2 (python >= 2.2).

http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-dependencies.html#RPM_Guide-Dependencies-obsoletes
___
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

[Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[Jim J. Jewett]

 
Vinay Sajip reworded the 'Provides-Dist' definition to explicitly say:

> 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 ...

(1)  Then how *should* the "bundle-of-several-components" case be
represented?

(2)  How is 'Provides-Dist' different from 'Obsoletes-Dist'?
The only difference I can see is that it may be a bit more polite
to people who do want to install multiple versions of a (possibly
abstract) package.


-jJ

-- 

If there are still threading problems with my replies, please 
email me with details, so that I can try to resolve them.  -jJ

___
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