Re: [Python-Dev] Accept just PEP-0426

On Tue, Nov 20, 2012 at 11:01 PM, Nick Coghlan wrote: > On Wed, Nov 21, 2012 at 1:20 PM, Nick Coghlan wrote: > >> On Wed, Nov 21, 2012 at 1:10 PM, PJ Eby wrote: >> >>> Conversely, if you have already installed a package that says it >>> "Obsoletes" another package, this does *not* tell you that

Re: [Python-Dev] Accept just PEP-0426

On Wed, Nov 21, 2012 at 1:20 PM, Nick Coghlan wrote: > On Wed, Nov 21, 2012 at 1:10 PM, PJ Eby wrote: > >> Conversely, if you have already installed a package that says it >> "Obsoletes" another package, this does *not* tell you that the obsolete >> package shouldn't still be installed! A repla

Re: [Python-Dev] Accept just PEP-0426

On Wed, Nov 21, 2012 at 1:10 PM, PJ Eby wrote: > Conversely, if you have already installed a package that says it > "Obsoletes" another package, this does *not* tell you that the obsolete > package shouldn't still be installed! A replacement project doesn't > necessarily share the same API, and

Re: [Python-Dev] Accept just PEP-0426

On Wed, Nov 21, 2012 at 12:44 PM, PJ Eby wrote: > > Can anybody suggest an *actual* use case for "Obsoletes", and explain how > it is supposed to work in software? The last time this discussion came up, > nobody had any use cases that stood up to the "how's that actually going to > work and/or h

Re: [Python-Dev] Accept just PEP-0426

On Tue, Nov 20, 2012 at 6:43 PM, Daniel Holth wrote: > No. We trust the packages we install, including the way they decide to use > the metadata. A bad package could delete all our files or cause dependency > resolution to fail. Mostly they won't. > That's sort of beside the point. The *only* u

Re: [Python-Dev] Accept just PEP-0426

On Tue, Nov 20, 2012 at 9:44 PM, PJ Eby wrote: > On Tue, Nov 20, 2012 at 5:01 PM, Daniel Holth wrote: > > http://www.python.org/dev/peps/pep-0314/ says: >> >> The most common use of this field will be in case a package name >> changes, e.g. Gorgon 2.3 gets subsumed into Torqued Pytho

Re: [Python-Dev] Accept just PEP-0426

On Tue, Nov 20, 2012 at 5:01 PM, Daniel Holth wrote: > http://www.python.org/dev/peps/pep-0314/ says: > > The most common use of this field will be in case a package name > changes, e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. > When you install Torqued Python, the Gor

Re: [Python-Dev] Accept just PEP-0426

On 11/20/2012 1:48 PM, PJ Eby wrote: (We've been over this before, the last time this discussion came up on the Distutils-SIG for a previous Metadata PEP a year or two back, but here goes) Thanks. I wasn't over there. Makes it clear that clarifying PEPs to reflect discussions is a good id

Re: [Python-Dev] Accept just PEP-0426

On Tue, Nov 20, 2012 at 06:43:32PM -0500, Daniel Holth wrote: > No. We trust the packages we install, including the way they decide to use > the metadata. A bad package could delete all our files or cause dependency > resolution to fail. Mostly they won't. > Agreed. And this is closer to the way

Re: [Python-Dev] Accept just PEP-0426

No. We trust the packages we install, including the way they decide to use the metadata. A bad package could delete all our files or cause dependency resolution to fail. Mostly they won't. Daniel Holth On Nov 20, 2012, at 5:26 PM, Vinay Sajip wrote: > Daniel Holth gmail.com> writes: > >> Th

Re: [Python-Dev] Accept just PEP-0426

Daniel Holth gmail.com> writes: > They mean pretty much what the same words mean in RPM and do not need further > bikeshedding. But isn't it the case that the scenarios are different because in the case of RPMs, we have a presumed authority which can determine e.g. what obsoletes what, whereas w

Re: [Python-Dev] Accept just PEP-0426

I think the Metadata 1.1 treatment of these concepts is in some ways better. (Metadata 1.2 added the -Dist suffix to the fields in an attempt to make it clear that dependency names are PyPI names and not "import x" names.) http://www.python.org/dev/peps/pep-0314/ says: Provides (multiple use)

Re: [Python-Dev] Accept just PEP-0426

On Tuesday, November 20, 2012 at 4:48 PM, PJ Eby wrote: > Words I agree that obsoletes is terrible, it's very specific and not something we particularly require. I'd much rather just have a generic "conflicts". ___ Python-Dev mailing list Python-Dev@pyth

Re: [Python-Dev] Accept just PEP-0426

On Tue, Nov 20, 2012 at 4:07 PM, Glenn Linderman wrote: > On 11/20/2012 12:46 PM, PJ Eby wrote: > > I personally don't think that forks claiming to "provide" something is > really a good thing to encourage; ISTM that saying a package *conflicts* > with another is more accurate, e.g. distribute C

Re: [Python-Dev] Accept just PEP-0426

On 11/20/2012 12:46 PM, PJ Eby wrote: On Tue, Nov 20, 2012 at 11:49 AM, Vinay Sajip > wrote: Also: what happens when a requirement is for setuptools (>= X.Y), but the distribute fork hasn't kept pace, and so only supports setuptools at a lower

Re: [Python-Dev] Accept just PEP-0426

On Tue, Nov 20, 2012 at 11:49 AM, Vinay Sajip wrote: > Also: what happens when a requirement is for setuptools (>= X.Y), but the > distribute fork hasn't kept pace, and so only supports setuptools at a > lower > version than X.Y? I take it we're entirely comfortable with installing > setuptools X.

Re: [Python-Dev] Accept just PEP-0426

Daniel Holth gmail.com> writes: > Edit the following text: Okay, here is a possible version: - Provides-Dist (multiple use) Each entry contains a string naming a requirement that is satisfied by installing this distribution. The entry must consist of a name an

Re: [Python-Dev] Accept just PEP-0426

On Wed, Nov 21, 2012 at 2:04 AM, Vinay Sajip wrote: > Nick Coghlan gmail.com> writes: > > > Provides/Requires/Obsoletes are *not* for bundling. Publishing bundled > packages > > on the index is bad, and people shouldn't do it. > [detail snipped] > > It's likely fine if an installer doesn't use so

Re: [Python-Dev] Accept just PEP-0426

Edit the following text: Provides-Dist (multiple use) Each entry contains a string naming a requirement that is satisfied by installing this distribution. This field *must* include the project identified in the ``Name`` field, optionally followed by the version Name (Version). A distribution m

Re: [Python-Dev] Accept just PEP-0426

Nick Coghlan gmail.com> writes: > Provides/Requires/Obsoletes are *not* for bundling. Publishing bundled > packages > on the index is bad, and people shouldn't do it. [detail snipped] > It's likely fine if an installer doesn't use sophisticated graph > analysis to find the "best" way to satisfy

Re: [Python-Dev] Accept just PEP-0426

On Wed, Nov 21, 2012 at 1:16 AM, Vinay Sajip wrote: > Daniel Holth gmail.com> writes: > > > If you don't have Provides-Dist, then distribute must continue to bundle > an > > extra .egg-info directory to emulate the feature. This is more than > enough > > justification for me. Name: is essentially

Re: [Python-Dev] Accept just PEP-0426

Daniel Holth gmail.com> writes: > If you don't have Provides-Dist, then distribute must continue to bundle an > extra .egg-info directory to emulate the feature. This is more than enough > justification for me. Name: is essentially an alias for Provides-Dist: (or > vice-versa) so there is no such

Re: [Python-Dev] Accept just PEP-0426

On Tue, Nov 20, 2012 at 9:35 AM, Vinay Sajip wrote: > Daniel Holth gmail.com> writes: > > > Mostly it seems a bit silly to have so much conversations about parts of > the > > pep that remain unchanged from previously accepted versions... > > I don't agree with the suggestion that we shouldn't dis

Re: [Python-Dev] Accept just PEP-0426

Daniel Holth gmail.com> writes: > Mostly it seems a bit silly to have so much conversations about parts of the > pep that remain unchanged from previously accepted versions... I don't agree with the suggestion that we shouldn't discuss it because it was accepted in a previous version. Perhaps it

Re: [Python-Dev] Accept just PEP-0426

The section could definitely be much clearer. How about: Provides-Dist (multiple use) Each entry contains a string naming a requirement that is satisfied by installing this distribution. This field *must* include the project identified in the ``Name`` field, optionally followed by the version: N

Re: [Python-Dev] Accept just PEP-0426

On Monday, November 19, 2012 at 9:24 PM, Daniel Holth wrote: > Mostly it seems a bit silly to have so much conversations about parts of the > pep that remain unchanged from previously accepted versions... Well, I think the PEP should describe what we expect to be implemented *shrug*. Either we

Re: [Python-Dev] Accept just PEP-0426

Mostly it seems a bit silly to have so much conversations about parts of the pep that remain unchanged from previously accepted versions... On Nov 19, 2012 8:33 PM, "Donald Stufft" wrote: > So you want to leave metadata in that you think people shouldn't > implement? > > Or you do think people s

Re: [Python-Dev] Accept just PEP-0426

On Monday, November 19, 2012 at 9:01 PM, Nick Coghlan wrote: > Look more closely at the docs for "Obsoletes" in RPM, not just those for > "Provides". Being able to transparently replace an existing package with a > renamed one that installs files with the same names is certainly part of the > pu

Re: [Python-Dev] Accept just PEP-0426

Look more closely at the docs for "Obsoletes" in RPM, not just those for "Provides". Being able to transparently replace an existing package with a renamed one that installs files with the same names is certainly part of the purpose/capabilities of the RPM dependency machinery (i.e. precisely the d

Re: [Python-Dev] Accept just PEP-0426

Daniel Holth writes: > Does [Provides-Dist] really have baggage? I think it is necessary, > although it doesn't do favors to the implementer (and has never > been implemented). How else is anyone supposed to fork or merge > projects? It doesn't bother me personally if this traffic is on pytho

Re: [Python-Dev] Accept just PEP-0426

On Monday, November 19, 2012 at 8:35 PM, Toshio Kuratomi wrote: > On Mon, Nov 19, 2012 at 07:49:41PM -0500, Donald Stufft wrote: > > Other languages seem to get along fine without it. Even the OS > > managers which have it don't allow it to be used to masquerade > > as another project, only to make

Re: [Python-Dev] Accept just PEP-0426

On Mon, Nov 19, 2012 at 07:49:41PM -0500, Donald Stufft wrote: > Other languages seem to get along fine without it. Even the OS > managers which have it don't allow it to be used to masquerade > as another project, only to make generic virtual packages (e.g. "email"). > I'm not sure this assertion

Re: [Python-Dev] Accept just PEP-0426

So you want to leave metadata in that you think people shouldn't implement? Or you do think people should implement it and the point about it existing forever without an implementation is? At the very least there needs to be some sort of guidelines as to what to do with the field in the various

Re: [Python-Dev] Accept just PEP-0426

We are getting along fine too. No tool parses metadata 1.x for package management reasons and provides has existed forever with no implementation. So it is not inconveniencing anyone. I would prefer to leave it alone. Daniel Holth On Nov 19, 2012, at 7:49 PM, Donald Stufft wrote: > Other lang

Re: [Python-Dev] Accept just PEP-0426

On Monday, November 19, 2012 at 8:08 PM, Daniel Holth wrote: > The distro repos are centrally managed, too. Try getting setuptools to > provide a virtual package just because you want to fork.. and then update the > dependent packages? > > Daniel Holth Sorry didn't mean to make it sound like I t

Re: [Python-Dev] Accept just PEP-0426

The distro repos are centrally managed, too. Try getting setuptools to provide a virtual package just because you want to fork.. and then update the dependent packages? Daniel Holth On Nov 19, 2012, at 7:49 PM, Donald Stufft wrote: > Other languages seem to get along fine without it. Even the

Re: [Python-Dev] Accept just PEP-0426

Other languages seem to get along fine without it. Even the OS managers which have it don't allow it to be used to masquerade as another project, only to make generic virtual packages (e.g. "email"). On Monday, November 19, 2012 at 7:43 PM, Daniel Holth wrote: > Does it really have baggage? I t

Re: [Python-Dev] Accept just PEP-0426

The "I bundled a renamed copy of six" is a totally different case which would not invoke provides-dist. "I merged sqlalchemy with a previously separate but wildly popular declarative / database support / whatever extension" would invoke provides-dist. Daniel Holth On Nov 19, 2012, at 7:41 PM,

Re: [Python-Dev] Accept just PEP-0426

Does it really have baggage? I think it is necessary, although it doesn't do favors to the implementer (and has never been implemented). How else is anyone supposed to fork or merge projects? Daniel Holth On Nov 19, 2012, at 7:37 PM, PJ Eby wrote: > On Mon, Nov 19, 2012 at 6:53 PM, Daniel Hol

Re: [Python-Dev] Accept just PEP-0426

On Monday, November 19, 2012 at 7:37 PM, PJ Eby wrote: > Can we maybe kill Provides-Dist and its associated baggage first, though? > > I would love to kill Provides-Dist. The biggest question there is how do you handle it's functionality? If someone needs setuptools but they have distribute ins

Re: [Python-Dev] Accept just PEP-0426

On Mon, Nov 19, 2012 at 6:53 PM, Daniel Holth wrote: > I think this PEP is a significant improvement from its predecessor. It > represents features like extras (provides-extra) and build requirements > (setup-requires-dist) that are in use in the Python community but cannot be > represented in ol

[Python-Dev] Accept just PEP-0426

I think this PEP is a significant improvement from its predecessor. It represents features like extras (provides-extra) and build requirements (setup-requires-dist) that are in use in the Python community but cannot be represented in older versions of the format, it finally specifies a UTF-8 encodi