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 u
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 patc
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 exercis
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, eit
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 pe
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
t
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 s
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
> > resea
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 "descr
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
>>
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 alrea
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,
> >
-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
> p
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
withou
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 confi
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 co
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 behav
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
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
> e
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 ins
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 pack
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
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 c
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
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 witho
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
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
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
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
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.
S
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 appear
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
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"
inform
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 abo
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 addresse
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 Obsolete
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
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 allowin
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
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 Wed
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 w
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
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
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.
> >
>
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
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 a
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
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 pro
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
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 e
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:
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?
>
> U
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 wr
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
>
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
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
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
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
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
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
60 matches
Mail list logo
