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

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 >

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

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

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

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

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

[Python-Dev] operator.attrgetter(attr[, args...]) etc.

Sorry the python issue tracker seems broken (I cannot log in). So I am posting it here. In the doc: operator.attrgetter(attr[, args...]) operator.itemgetter(item[, args...]) operator.methodcaller(name[, args...]) The signatures of these functions seem confusing. ARGS is not documented and

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] Keyword meanings [was: Accept just PEP-0426]

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 f

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] Keyword meanings [was: Accept just PEP-0426]

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 w

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] [Python-checkins] cpython (3.3): - Issue #16514: Fix regression causing a traceback when sys.path[0] is None

On Nov 20, 2012, at 05:35 PM, Terry Reedy wrote: >On 11/20/2012 3:35 PM, barry.warsaw wrote: > >> for entry in path: >> +if not isinstance(entry, (str, bytes)): >> +continue > >Given that a non-(str,bytes) entry could indicate a programming error, should >a wa

Re: [Python-Dev] [Python-checkins] cpython (3.3): - Issue #16514: Fix regression causing a traceback when sys.path[0] is None

On Nov 20, 2012, at 05:12 PM, Brett Cannon wrote: >Should you also insert None into sys.path_importer_cache to signify there >is no finder for the path entry? I guess the real problem with that is >there is no guarantee the path entry is hashable, so that probably won't >work. So nevermind. =) I

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] [Python-checkins] cpython (3.3): - Issue #16514: Fix regression causing a traceback when sys.path[0] is None

Should you also insert None into sys.path_importer_cache to signify there is no finder for the path entry? I guess the real problem with that is there is no guarantee the path entry is hashable, so that probably won't work. So nevermind. =) On Tue, Nov 20, 2012 at 3:35 PM, barry.warsaw wrote: >

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] Keyword meanings [was: Accept just PEP-0426]

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 merg

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

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

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

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] Generally boared by installation (Re: Setting project home path the best way)

On Tue, Nov 20, 2012 at 9:44 AM, Nick Coghlan wrote: > On Tue, Nov 20, 2012 at 11:45 PM, Christian Tismer > wrote: > >> On 20.11.12 12:39, Nick Coghlan wrote: >> >> On Tue, Nov 20, 2012 at 7:06 PM, Kristján Valur Jónsson < >> krist...@ccpgames.com> wrote: >> >>> I’m intrigued. I thought this

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] Generally boared by installation (Re: Setting project home path the best way)

On Tue, Nov 20, 2012 at 11:45 PM, Christian Tismer wrote: > On 20.11.12 12:39, Nick Coghlan wrote: > > On Tue, Nov 20, 2012 at 7:06 PM, Kristján Valur Jónsson < > krist...@ccpgames.com> wrote: > >> I’m intrigued. I thought this was merely so that one could do >> >> python –m mypackage.mysubpack

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] Generally boared by installation (Re: Setting project home path the best way)

On 20.11.12 12:39, Nick Coghlan wrote: On Tue, Nov 20, 2012 at 7:06 PM, Kristján Valur Jónsson mailto:krist...@ccpgames.com>> wrote: I’m intrigued. I thought this was merely so that one could do python –m mypackage.mysubpackage Can you refer me to the rationale and discussion abo

Re: [Python-Dev] Generally boared by installation (Re: Setting project home path the best way)

On Tue, Nov 20, 2012 at 7:06 PM, Kristján Valur Jónsson < krist...@ccpgames.com> wrote: > I’m intrigued. I thought this was merely so that one could do > > python –m mypackage.mysubpackage > > Can you refer me to the rationale and discussion about this feature? > It was part of a fairly

Re: [Python-Dev] Generally boared by installation (Re: Setting project home path the best way)

I'm intrigued. I thought this was merely so that one could do python -m mypackage.mysubpackage Can you refer me to the rationale and discussion about this feature? K From: Nick Coghlan [mailto:ncogh...@gmail.com] Sent: 18. nóvember 2012 11:25 To: Kristján Valur Jónsson Cc: Christian Tismer; pyth