Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
On Wed, Aug 15, 2012 at 10:49 AM, Daniel Holth wrote: > I've drafted some edits to Metadata 1.2 with valuable feedback from ... > (full changeset on > https://bitbucket.org/dholth/python-peps/changeset/537e83bd4068) Metadata 1.2 is nearly 8 years old and it's Accepted but not Final. Is it better to continue editing it, or create a new PEP for Metadata 1.3? ___ 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] Edits to Metadata 1.2 to add extras (optional dependencies)
Am 27.08.12 16:56, schrieb Daniel Holth: On Wed, Aug 15, 2012 at 10:49 AM, Daniel Holth wrote: I've drafted some edits to Metadata 1.2 with valuable feedback from ... (full changeset on https://bitbucket.org/dholth/python-peps/changeset/537e83bd4068) Metadata 1.2 is nearly 8 years old and it's Accepted but not Final. Is it better to continue editing it, or create a new PEP for Metadata 1.3? You can't add new fields to the format after the fact, unless the format had provided for such additions (which it does not - there is no mention of custom fields anywhere, and no elaboration on how "unknown" fields should be processed). So if you want to add new fields, you need to create a new version of the metadata. Prepare for a ten-year period of acceptance - so it would be good to be sure that no further additions are desired within the next ten years before seeking approval for the PEP. Regards, Martin ___ 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] Edits to Metadata 1.2 to add extras (optional dependencies)
On Mon, Aug 27, 2012 at 4:29 PM, "Martin v. Löwis" wrote: > Am 27.08.12 16:56, schrieb Daniel Holth: > >> On Wed, Aug 15, 2012 at 10:49 AM, Daniel Holth wrote: >>> >>> I've drafted some edits to Metadata 1.2 with valuable feedback from >> >> ... >>> >>> (full changeset on >>> https://bitbucket.org/dholth/python-peps/changeset/537e83bd4068) >> >> >> Metadata 1.2 is nearly 8 years old and it's Accepted but not Final. Is >> it better to continue editing it, or create a new PEP for Metadata >> 1.3? > > > You can't add new fields to the format after the fact, unless the format had > provided for such additions (which it does not - there is > no mention of custom fields anywhere, and no elaboration on how > "unknown" fields should be processed). > > So if you want to add new fields, you need to create a new version > of the metadata. Prepare for a ten-year period of acceptance - so it > would be good to be sure that no further additions are desired within > the next ten years before seeking approval for the PEP. I don't know of a tool that doesn't reliably ignore extra fields, but I will put you down as being in favor of an X- fields paragraph: Extensions (X- Fields) :: Metadata files can contain fields that are not part of the specification, called *extensions*. These fields start with with `X-`. ___ 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] Edits to Metadata 1.2 to add extras (optional dependencies)
Daniel Holth wrote: > I don't know of a tool that doesn't reliably ignore extra fields, but > I will put you down as being in favor of an X- fields paragraph: > > Extensions (X- Fields) > :: > > Metadata files can contain fields that are not part of > the specification, called *extensions*. These fields start with > with `X-`. See RFC 6648 for why such X-fields may not be a good idea: http://tools.ietf.org/html/rfc6648 ___ 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] question re: default branch and release clone
Georg Brandl wrote: > Changes to the default branch must be bugfix-only. The 3.4 development > only opens when the 3.3 branch is created, which happens after the > release of 3.3.0 final. > > Changes made in default and not cherry-picked to the 3.3.0 release clone > will therefore end up in 3.3.1 and 3.4. Where should I put the news entry for fixes that will go to 3.3.1? The top item in Misc/NEWS is 3.3.0 RC 2. The stuff in your private clone will be released as 3.3.0, so can a 3.3.1 entry be added to the default branch of the public repo now? And if changes like this are added now, they will be included in 3.2.4 but not in 3.3.0. Is this bad? Petri ___ 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] Edits to Metadata 1.2 to add extras (optional dependencies)
Petri Lehtinen writes: > Daniel Holth wrote: > > I don't know of a tool that doesn't reliably ignore extra fields, but > > I will put you down as being in favor of an X- fields paragraph: > > > > Extensions (X- Fields) > > :: > > > > Metadata files can contain fields that are not part of > > the specification, called *extensions*. These fields start with > > with `X-`. > > See RFC 6648 for why such X-fields may not be a good idea: > > http://tools.ietf.org/html/rfc6648 But note that the RFC also says that the preferred solution to the problem that X-fields are intended to solve is an easily accessible name registry and a simple registration procedure. If Martin's "be prepared for a ten-year period to acceptance" is serious, what should be done about such a registry? ___ 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] question re: default branch and release clone
On 28.08.2012 06:22, Petri Lehtinen wrote: Georg Brandl wrote: Changes to the default branch must be bugfix-only. The 3.4 development only opens when the 3.3 branch is created, which happens after the release of 3.3.0 final. Changes made in default and not cherry-picked to the 3.3.0 release clone will therefore end up in 3.3.1 and 3.4. Where should I put the news entry for fixes that will go to 3.3.1? The top item in Misc/NEWS is 3.3.0 RC 2. The stuff in your private clone will be released as 3.3.0, so can a 3.3.1 entry be added to the default branch of the public repo now? Yes. And if changes like this are added now, they will be included in 3.2.4 but not in 3.3.0. Is this bad? Sounds fine to me. Georg ___ 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] Edits to Metadata 1.2 to add extras (optional dependencies)
On Tue, Aug 28, 2012 at 6:29 AM, "Martin v. Löwis" wrote: > Am 27.08.12 16:56, schrieb Daniel Holth: >> Metadata 1.2 is nearly 8 years old and it's Accepted but not Final. Is >> it better to continue editing it, or create a new PEP for Metadata >> 1.3? > > > You can't add new fields to the format after the fact, unless the format had > provided for such additions (which it does not - there is > no mention of custom fields anywhere, and no elaboration on how > "unknown" fields should be processed). > > So if you want to add new fields, you need to create a new version > of the metadata. I agree with this point - the main reason the metadata PEP is still lingering at Accepted rather than Final is the tangled relationship between distutils and other projects that led to the complete distutils feature freeze. Until distutils2 makes it into the standard library as the packaging module, the standard library is going to be stuck at v1.1 of the metadata format. > Prepare for a ten-year period of acceptance - so it > would be good to be sure that no further additions are desired within > the next ten years before seeking approval for the PEP. However, this point I really don't agree with. The packaging ecosystem is currently evolving outside the standard library, but the standardisation process for the data interchange formats still falls under the authority of python-dev and the PEP process. If there are things missing from v1.2 of the metadata spec, then define v1.3 to address those known problems. Don't overengineer it in an attempt to anticipate every possible need that might come in the next decade. Tools outside the standard library are then free to adopt the new standard, even while the stdlib itself continues to lag behind. When the packaging module is finally added (hopefully 3.4, even if that means we have to temporarily cull the entire compiler subpackage), it will handle the most recent accepted version of the metadata format (as well as any previous versions). If more holes reveal themselves in the next 18 months, then it's OK if v1.4 is created when it becomes clear that it's necessary. At the very least, something v1.3 should make explicit is that custom metadata should NOT be put into the .dist-info/METADATA (PEP 376 location, PKG-INFO, in distutils terms) file. Instead, that data should be placed in a *separate* file in the .dist-info directory. Something that *may* be appropriate is a new field in METADATA that explicitly calls out such custom metadata files by naming the PyPI distribution that is the authority for the relevant format (e.g. "Custom-Metadata: wheel" to indicate that 'wheel' defined metadata is present) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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
