Re: [Python-Dev] need reviewers for #16475 and #16487
Thank you! The sensitivity of this issue obviously is born out of our collective bad conscience for this unjust incarceration. K > -Original Message- > From: [email protected] [mailto:[email protected]] On Behalf > Of Guido van Rossum > > > > This fixes a regression in marshal between 2.x and 3.x, reinstating > > string reuse and internment support. In addition, it generalizes > > string reuse to > > It's not internment -- that means imprisonment. The term we use is > interning. (The dictionary will tell you that means imprisonment too > -- but it's long been used as the name for this particular technique. > Internment has not.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] externals?
But that's what hg clone does. You have a lorry for your work at the mine. You don't need a Mini to go to the fishmongers. You can use your lorry even if you are not going to dump a tonne of ore on the pavement. K > -Original Message- > > What would be good would to be able to access the files and use them to > build python without svn installed. I don't know the best way to do that, but > if tarred or zipped releases were made for each version that should be > downloaded, our urllib, tarfile/ziplib, and any other modules needed should > be sufficient to transfer and unpack. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] externals?
On Sun, Nov 18, 2012 at 04:18:43AM -0800, [email protected] wrote: > I'd like to stress that we don't need any versioning here. wget and > tar would be sufficient, except that it's Windows, so we have neither > wget nor tar. However, including a PowerShell script may be an option; > most developers will have PowerShell already on their system. AFAICT, > PowerShell can do HTTP downloads and extract zip files. I'm disturbed that I subconsciously interpreted this as a challenge to do it via a standalone batch/.bat ;-) Trent. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New Contributor Experience in Python and other FOSS Communities - A Survey
Hi all, Along with a number of other free and open communities, Python is being included in a survey of new contributors since January 2010. The survey is being done by Kevin Carillo, a PhD student at Victoria University of Wellington who is studying various approaches that projects use to gain and work with new contributors. If you have written patches, reviewed issues, or done anything to contribute to the development of Python and you started this after January 2010, I hope you can spare around 20 minutes to complete this survey: https://limesurvey.sim.vuw.ac.nz/index.php?sid=65151&lang=en There's a longer blog post up at http://blog.python.org/2012/11/new-contributor-experience-in-python.html if you would like a bit more information. On behalf of Kevin Carillo, I thank you for your time and consideration of this survey. Brian Curtin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 encoding, removes RFC 822, provides an extension mechanism, and allows the description to be placed in the document payload. PEP 426 doesn't have anything to do with the Wheel PEPs 425 and 427, other than that its features are necessary to usefully represent a large number of existing Python packages. How about moving this one along to focus on the other two. I'm not sure what the Post-History should be. We have been talking about it for a while. Thanks, Daniel Holth PEP: 426 Title: Metadata for Python Software Packages 1.3 Version: $Revision$ Last-Modified: $Date$ Author: Daniel Holth Discussions-To: Distutils SIG Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 30 Aug 2012 Abstract This PEP describes a mechanism for adding metadata to Python distributions. It includes specifics of the field names, and their semantics and usage. This document specifies version 1.3 of the metadata format. Version 1.0 is specified in PEP 241. Version 1.1 is specified in PEP 314. Version 1.2 is specified in PEP 345. Version 1.3 of the metadata format adds fields designed to make third-party packaging of Python Software easier and defines a formal extension mechanism. The fields are "Setup-Requires-Dist" "Provides-Extra", and "Extension". This version also adds the `extra` variable to the `environment markers` specification and allows the description to be placed into a payload section. Metadata Files == The syntax defined in this PEP is for use with Python distribution metadata files. The file format is a simple UTF-8 encoded Key: value format with case-insensitive keys and no maximum line length, followed by a blank line and an arbitrary payload. It is parseable by the ``email`` module with an appropriate ``email.policy.Policy()``. When ``metadata`` is a Unicode string, ```email.parser.Parser().parsestr(metadata)`` is a serviceable parser. There are two standard locations for these metadata files: * the ``PKG-INFO`` file included in the base directory of Python source distribution archives (as created by the distutils ``sdist`` command) * the ``.dist-info/METADATA`` files in a Python installation database, as described in PEP 376. Other tools involved in Python distribution may also use this format. Encoding Metadata 1.3 files are UTF-8 with the restriction that keys must be ASCII. Parser implementations should be aware that older versions of the Metadata specification do not specify an encoding. Fields == This section specifies the names and semantics of each of the supported metadata fields. In a single Metadata 1.3 file, fields marked with "(optional)" may occur 0 or 1 times. Fields marked with "(multiple use)" may be specified 0, 1 or more times. Only "Metadata-Version", "Name", "Version", and "Summary" must appear exactly once. The fields may appear in any order within the file. Metadata-Version Version of the file format; "1.3" is the only legal value. Example:: Metadata-Version: 1.3 Name The name of the distribution. Example:: Name: BeagleVote Version ::: A string containing the distribution's version number. This field must be in the format specified in PEP 386. Example:: Version: 1.0a2 Summary ::: A one-line summary of what the distribution does. Example:: Summary: A module for collecting votes from beagles. Platform (multiple use) ::: A Platform specification describing an operating system supported by the distribution which is not listed in the "Operating System" Trove classifiers. See "Classifier" below. Examples:: Platform: ObscureUnix Platform: RareDOS Supported-Platform (multiple use) : Binary distributions containing a metadata file will use the Supported-Platform field in their metadata to specify the OS and CPU for which the binary distribution was compiled. The semantics of the Supported-Platform field are not specified in this PEP. Example:: Supported-Platform: RedHat 7.2 Supported-Platform: i386-win32-2791 Description (optional, deprecated) :: A longer description of the distribution that can run to several paragraphs. Software that deals with metadata should not assume any maximum size for this field. The contents of this field can be written using reStructuredText markup [1]_. For programs that work with the metadata, supporting markup is optional; programs can also display the contents of the field as-is. This means that authors should be conservative in the markup they use. Since a line separator immediately followed by another line separat
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 older versions of the format, it finally specifies a UTF-8 > encoding, removes RFC 822, provides an extension mechanism, and allows the > description to be placed in the document payload. > Can we maybe kill Provides-Dist and its associated baggage first, though? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 installed they both shouldn't get installed. The need for it for the "2 packages being distributed together" I'm (personally) less concerned about since with proper dependency data we should be able to just depend on things instead of bundling them. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 older versions of the format, it finally specifies a UTF-8 >> encoding, removes RFC 822, provides an extension mechanism, and allows the >> description to be placed in the document payload. > > Can we maybe kill Provides-Dist and its associated baggage first, though? > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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, Donald Stufft wrote: > 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 installed > they > both shouldn't get installed. > > The need for it for the "2 packages being distributed together" I'm > (personally) > less concerned about since with proper dependency data we should be > able to just depend on things instead of bundling them. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 (mailto:[email protected])> wrote: > > > On Mon, Nov 19, 2012 at 6:53 PM, Daniel Holth > (mailto:[email protected])> 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 older versions of the format, it finally specifies a > > > UTF-8 encoding, removes RFC 822, provides an extension mechanism, and > > > allows the description to be placed in the document payload. > > > > Can we maybe kill Provides-Dist and its associated baggage first, though? > > > ___ > Python-Dev mailing list > [email protected] (mailto:[email protected]) > 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 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 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 older versions of the format, it finally specifies a UTF-8 encoding, removes RFC 822, provides an extension mechanism, and allows the description to be placed in the document payload. >>> >>> Can we maybe kill Provides-Dist and its associated baggage first, though? >>> >> >> ___ >> Python-Dev mailing list >> [email protected] >> 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 thought we should do it like the OS packagers, just mentioning that very few (any?) other languages do it like that and they seem to be getting along just fine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 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 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 older versions of the format, it finally specifies a UTF-8 encoding, removes RFC 822, provides an extension mechanism, and allows the description to be placed in the document payload. >>> >>> Can we maybe kill Provides-Dist and its associated baggage first, though? >>> >> >> ___ >> Python-Dev mailing list >> [email protected] >> 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 states it could be in. On Monday, November 19, 2012 at 8:31 PM, Daniel Holth wrote: > 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 (mailto:[email protected])> 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"). > > > > On Monday, November 19, 2012 at 7:43 PM, Daniel Holth wrote: > > > > > 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 > > (mailto:[email protected])> wrote: > > > > > > > On Mon, Nov 19, 2012 at 6:53 PM, Daniel Holth > > > (mailto:[email protected])> 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 older versions of the format, > > > > > it finally specifies a UTF-8 encoding, removes RFC 822, provides an > > > > > extension mechanism, and allows the description to be placed in the > > > > > document payload. > > > > > > > > Can we maybe kill Provides-Dist and its associated baggage first, > > > > though? > > > > > > > ___ > > > Python-Dev mailing list > > > [email protected] (mailto:[email protected]) > > > 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 about OS package managers is correct. I've only just read: http://www.python.org/dev/peps/pep-0426/#provides-dist-multiple-use but the rough rpm analogue seems to be the Provides: tag. Provides is given a string which is parsed into a name or a name and version like this: Provides: python Provides: python = 3.1.0 rpm has no way at package build time to tell that a particular name given in a provides in one package is the actual name of another package. At installtime, rpm keeps package names and provides names separately but in dependency comparisons either one can be used to satisfy a requirement. What that means is that when asking about information on a package with name "python", you'll get information about the python package with that name and not about anything else that Provides: "python". But if you are installing something that has a requirement on "python" either the package with the name python or any package that Provides: python can satisfy the requirement. Package managers with builtin dep solvers can be built on top of rpm. The one that I am familiar with is yum. Since yum is downloading the packages that are being fed into rpm, yum could choose to prefer the package name instead of things in Provides when it downloads. It doesn't, though. Just like the underlying rpm, it treats package names and names specificed through Provides: as equivalent. -Toshio > On Monday, November 19, 2012 at 7:43 PM, Daniel Holth wrote: > > 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 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 older versions of the > format, it finally specifies a UTF-8 encoding, removes RFC 822, > provides an extension mechanism, and allows the description to be > placed in the document payload. > > > Can we maybe kill Provides-Dist and its associated baggage first, > though? > > > ___ > Python-Dev mailing list > [email protected] > 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 > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/a.badger%40gmail.com pgpCdA0z048OX.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 generic virtual packages (e.g. "email"). > > > > I'm not sure this assertion about OS package managers is correct. I've only > just read: > http://www.python.org/dev/peps/pep-0426/#provides-dist-multiple-use > > but the rough rpm analogue seems to be the Provides: tag. > > Provides is given a string which is parsed into a name or a name and version > like this: > > Provides: python > Provides: python = 3.1.0 > > rpm has no way at package build time to tell that a particular name given in > a provides in one package is the actual name of another package. > > At installtime, rpm keeps package names and provides names separately but in > dependency comparisons either one can be used to satisfy a requirement. > What that means is that when asking about information on a package with name > "python", you'll get information about the python package with that name and > not about anything else that Provides: "python". But if you are installing > something that has a requirement on "python" either the package with the > name python or any package that Provides: python can satisfy the requirement. > Are you saying the RPM documentation is wrong? http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html The provides tag is used to specify a *virtual package* that the packaged software makes available when it is installed. Normally, this tag would be used when different packages provide equivalent services. For example, any package that allows a user to read mail might provide the mail-reader virtual package. Another package that depends on a mail reader of some sort, could require the mail-reader virtual package. It would then install without dependency problems, if any one of several mail programs were installed. It pretty clearly states that it is not to be used for masquerading as a different package, which was my point. I wasn't making any claims about wether it was technically possible to do so or not, just what it's intended purpose was. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 python-dev, but this looks rather technical. Shouldn't the distutils-sig at least be CC'd? Steve ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 distribute vs setuptools situation). We may want to clarify the wording to ensure it is clear that the provision of the dist name (as posted on PyPI) is implied, though. Cheers, Nick. -- Sent from my phone, thus the relative brevity :) On Nov 20, 2012 11:45 AM, "Donald Stufft" wrote: > 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 generic virtual packages (e.g. "email"). > > I'm not sure this assertion about OS package managers is correct. I've only > just read: > http://www.python.org/dev/peps/pep-0426/#provides-dist-multiple-use > > but the rough rpm analogue seems to be the Provides: tag. > > Provides is given a string which is parsed into a name or a name and > version > like this: > > Provides: python > Provides: python = 3.1.0 > > rpm has no way at package build time to tell that a particular name given > in > a provides in one package is the actual name of another package. > > At installtime, rpm keeps package names and provides names separately but > in > dependency comparisons either one can be used to satisfy a requirement. > What that means is that when asking about information on a package with > name > "python", you'll get information about the python package with that name > and > not about anything else that Provides: "python". But if you are installing > something that has a requirement on "python" either the package with the > name python or any package that Provides: python can satisfy the > requirement. > > Are you saying the RPM documentation is wrong? > > http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html > > The provides tag is used to specify a *virtual package* that the packaged > software makes available when it is installed. Normally, this tag would be > used when different packages provide equivalent services. For example, > any package that allows a user to read mail might provide the mail-reader > virtual package. Another package that depends on a mail reader of some > sort, could require the mail-reader virtual package. It would then install > without dependency problems, if any one of several mail programs were > installed. > > It pretty clearly states that it is not to be used for masquerading as a > different package, which was my point. I wasn't making any claims about > wether it was technically possible to do so or not, just what it's intended > purpose was. > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 > purpose/capabilities of the RPM dependency machinery (i.e. precisely the > distribute vs setuptools situation). > We may want to clarify the wording to ensure it is clear that the provision > of the dist name (as posted on PyPI) is implied, though. > Cheers, > Nick. I'm not sure if you're responding to me or not, but we also have Obsoletes-Dist in the metadata. (Which I don't like the name of but that's for another argument). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 states it could be in. > > On Monday, November 19, 2012 at 8:31 PM, Daniel Holth wrote: > > 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 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 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 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 older versions of the format, it finally specifies a UTF-8 > encoding, removes RFC 822, provides an extension mechanism, and allows the > description to be placed in the document payload. > > > Can we maybe kill Provides-Dist and its associated baggage first, though? > > ___ > Python-Dev mailing list > [email protected] > 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 should expect it to be implemented and it should be part of the spec, or we shouldn't expect people to implement it and it should be removed. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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: Name (Version). A distribution may provide additional names, e.g. to indicate that multiple projects have been merged into a single distribution or to indicate that this project is a substitute for another. For instance distribute (a fork of setuptools) could ``Provides-Dist`` setuptools to prevent the conflicting package from being downloaded and installed when distribute is already installed. A distribution that has been merged with another might ``Provides-Dist`` the obsolete name(s) to satisfy any projects that require the obsolete distribution's name. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
