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
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
ownwink/, and not by others, either.
So, unfortunately, I was left with the conventional opposition in
On Sun, Dec 9, 2012 at 10:38 PM, Andrew McNabb amcn...@mcnabbs.org 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
On Mon, Dec 10, 2012 at 3:27 AM, Stephen J. Turnbull step...@xemacs.org 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
ownwink/, and not by
On Fri, Dec 7, 2012 at 10:46 PM, PJ Eby p...@telecommunity.com 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
On 10 December 2012 16:35, Toshio Kuratomi a.bad...@gmail.com 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
On Sun, Dec 9, 2012 at 12:54 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Dec 9, 2012 at 6:18 AM, PJ Eby p...@telecommunity.com wrote:
On Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby p...@telecommunity.com wrote:
So if
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
On Sun, Dec 9, 2012 at 8:48 PM, Stephen J. Turnbull step...@xemacs.org 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*
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
On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby p...@telecommunity.com 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
On Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby p...@telecommunity.com 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
On 2012-12-08 20:18, PJ Eby wrote:
On Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby p...@telecommunity.com wrote:
So if package A includes a Conflicts: B declaration, I recommend the
following:
* An attempt to install A with B
-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
On Sun, Dec 9, 2012 at 8:41 AM, Tres Seaver tsea...@palladion.com 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
On Sun, Dec 9, 2012 at 6:18 AM, PJ Eby p...@telecommunity.com wrote:
On Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby p...@telecommunity.com wrote:
So if package A includes a Conflicts: B declaration, I recommend the
following:
On Fri, Dec 07, 2012 at 01:18:40AM -0500, PJ Eby wrote:
On Thu, Dec 6, 2012 at 1:49 AM, Toshio Kuratomi a.bad...@gmail.com 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 donald.stu...@gmail.com
wrote:
Nobody has actually
On Fri, Dec 7, 2012 at 12:01 PM, Toshio Kuratomi a.bad...@gmail.com 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 a.bad...@gmail.com wrote:
On Wed, Dec 05, 2012 at 07:34:41PM -0500, PJ Eby wrote:
Nobody has actually proposed a
On Fri, Dec 7, 2012 at 3:47 PM, PJ Eby p...@telecommunity.com 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
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
On Sat, Dec 8, 2012 at 8:02 AM, PJ Eby p...@telecommunity.com 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
On Fri, Dec 7, 2012 at 8:33 PM, Nick Coghlan ncogh...@gmail.com 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,
Donald Stufft donald.stufft at 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
On Thursday, December 6, 2012 at 6:28 AM, Vinay Sajip wrote:
Donald Stufft donald.stufft at 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
On Thu, Dec 6, 2012 at 6:33 AM, Donald Stufft donald.stu...@gmail.comwrote:
On Thursday, December 6, 2012 at 6:28 AM, Vinay Sajip wrote:
Donald Stufft donald.stufft at gmail.com writes:
Never mind the Obsoletes information - even the more useful
Requires-Dist
information is not exposed via
Daniel Holth dholth at 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
On Thu, Dec 6, 2012 at 9:58 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Daniel Holth dholth at 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
On 6 Dec, 2012, at 15:58, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Daniel Holth dholth at 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
Daniel Holth dholth at 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
On Thu, Dec 6, 2012 at 11:30 AM, Vinay Sajip vinay_sa...@yahoo.co.ukwrote:
Daniel Holth dholth at 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
On Thu, Dec 6, 2012 at 8:39 AM, Daniel Holth dho...@gmail.com 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
On Thu, Dec 6, 2012 at 9:58 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Daniel Holth dholth at 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
On Thu, Dec 6, 2012 at 1:49 AM, Toshio Kuratomi a.bad...@gmail.com 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 donald.stu...@gmail.com
wrote:
Nobody has actually proposed a better one, outside of package renaming
-- and that
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 dho...@gmail.com wrote:
How to use Obsoletes:
The author of B decides A is obsolete.
A
On Wed, Dec 5, 2012 at 2:46 AM, Donald Stufft donald.stu...@gmail.com 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
On Wed, Dec 5, 2012 at 4:10 PM, PJ Eby p...@telecommunity.com wrote:
On Wed, Dec 5, 2012 at 2:46 AM, Donald Stufft donald.stu...@gmail.com
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
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 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
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 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
On Wed, Dec 5, 2012 at 5:30 PM, Daniel Holth dho...@gmail.com 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
On Wed, Dec 5, 2012 at 6:07 PM, Donald Stufft donald.stu...@gmail.com 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
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
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
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 Thu, Dec 6, 2012 at 8:30 AM, Daniel Holth dho...@gmail.com 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
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
On Thu, Dec 6, 2012 at 1:12 PM, Daniel Holth dho...@gmail.com 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,
On Thu, Dec 6, 2012 at 2:54 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Dec 6, 2012 at 1:12 PM, Daniel Holth dho...@gmail.com 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
On Wed, Dec 05, 2012 at 07:34:41PM -0500, PJ Eby wrote:
On Wed, Dec 5, 2012 at 6:07 PM, Donald Stufft donald.stu...@gmail.com 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
On Mon, Dec 3, 2012 at 2:43 PM, Daniel Holth 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?
On Wednesday, December 5, 2012 at 2:13 AM, PJ Eby wrote:
On Mon, Dec 3, 2012 at 2:43 PM, Daniel Holth dho...@gmail.com
(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
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
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
On Tue, Nov 20, 2012 at 3:58 PM, Jim J. Jewett jimjjew...@gmail.com 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
On 11/20/12, Daniel Holth dho...@gmail.com wrote:
On Tue, Nov 20, 2012 at 3:58 PM, Jim J. Jewett jimjjew...@gmail.com
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
On Tue, Nov 20, 2012 at 7:18 PM, Jim Jewett jimjjew...@gmail.com wrote:
On 11/20/12, Daniel Holth dho...@gmail.com wrote:
On Tue, Nov 20, 2012 at 3:58 PM, Jim J. Jewett jimjjew...@gmail.com
wrote:
Vinay Sajip reworded the 'Provides-Dist' definition to explicitly say:
The use of
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 Wed, Nov 21, 2012 at 12:00 AM, Stephen J. Turnbull step...@xemacs.orgwrote:
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
PJ Eby writes:
On Wed, Nov 21, 2012 at 12:00 AM, Stephen J. Turnbull
step...@xemacs.orgwrote:
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
60 matches
Mail list logo
