Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
On Aug 28, 2012, at 1:20 AM, Nick Coghlan wrote: > 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) Setuptools just uses path.exists() when it needs a particular file and will not bother parsing pkg-info at all if it can help it. The metadata edits for 1.2 fold some of those files into metadata. ___ 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 9:04 PM, Daniel Holth wrote: > Setuptools just uses path.exists() when it needs a particular file and will > not bother parsing pkg-info at all if it can help it. The metadata edits for > 1.2 fold some of those files into metadata. You can't use path.exists() on metadata published by a webservice (or still inside a zipfile), but you can download or read the main metadata file. Still, I don't really care whether or not such a field indicating the presence of custom metadata is added, I'm mainly registering a strong -1 on allowing extension fields (in the form of X- headers or CSS style prefixed headers) in the metadata file itself. 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
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
I personally think that at a minimum we should have X-Fields that get moved into the normal METADATA file, and personally I would prefer to just drop the X- prefix completely. I think any spec which doesn't include first class support for extending it with new metadata is going to essentially kick the can down the road and solve the problems of today without leaving room to solve the problems of tomorrow. I know that distutils2 have requires-dist, but for the sake of argument pretend they don't. If there is first class support for extending the metadata with new fields, a project could come along, and add a requires-dist (or x-requires-dist) concept to metadata. Tools that understand it would see that data and be able to act on it, tools that don't understand it would simply write it to the METADATA file incase in the future a tool that does understand it needs to act on it. Essentially first class support for extending the metadata outside of a PEP process means that outside of the stdlib people can experiment and try new things, existing tools will continue to work and just ignore that extra data (but leave it intact), new tools will be able to utilize it to do something useful. Ideally as a new concept is tested externally and begins to gain acceptance a new metadata version could be created that standardizes that field as part of the spec instead of an extension. On Tuesday, August 28, 2012 at 7:45 AM, Nick Coghlan wrote: > On Tue, Aug 28, 2012 at 9:04 PM, Daniel Holth (mailto:[email protected])> wrote: > > Setuptools just uses path.exists() when it needs a particular file and will > > not bother parsing pkg-info at all if it can help it. The metadata edits > > for 1.2 fold some of those files into metadata. > > > You can't use path.exists() on metadata published by a webservice (or > still inside a zipfile), but you can download or read the main > metadata file. > > Still, I don't really care whether or not such a field indicating the > presence of custom metadata is added, I'm mainly registering a strong > -1 on allowing extension fields (in the form of X- headers or CSS > style prefixed headers) in the metadata file itself. > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] (mailto:[email protected]) | Brisbane, > Australia > ___ > 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] Edits to Metadata 1.2 to add extras (optional dependencies)
On Tue, Aug 28, 2012 at 8:07 AM, Donald Stufft wrote: > I personally think that at a minimum we should have X-Fields that > get moved into the normal METADATA file, and personally I would > prefer to just drop the X- prefix completely. That is my preference as well. The standard library basically ignores every metadata field or metadata file inside or outside of metadata currently, so where is the harm changing the official document to read "you may add new metadata fields to metadata" with an updated standard library that only ignores some of the metadata in metadata instead of all of it. The community is small enough to handle it. ___ 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 10:07 PM, Donald Stufft wrote: > I personally think that at a minimum we should have X-Fields that > get moved into the normal METADATA file, and personally I would > prefer to just drop the X- prefix completely. Hell no. We've been down this road with setuptools and it *sucks*. Everybody gets confused, because you can't tell just by looking at a metadata file what's part of the standard and what's been added just because a tool developer thought it was a good idea without being able to obtain broad consensus (perhaps because others couldn't see the point until the extension had been field tested for an extended period). Almost *nobody* reads metadata specs other than the people that helped write them. Everyone else copies a file that works, and tweaks it to suit, or they use a tool that generates the metadata for them based on some other interface. The least-awful widespread extension approach I'm aware of is CSS vendor prefixes. X- headers suck because they only give you two namespaces - the "standard" namespace and the "extension" namespace. That means everyone is quickly forced back into seeking agreement and consensus to avoid naming conflicts for extension fields. However, I'm open to the idea of a properly namespaced extension mechanism, which is exactly why I suggested separate files flagged in the main metadata with the PyPI project that defines the format of those extensions. I'm also open to the idea of extensions appearing in [PyPI distribution] prefixed sections after the standard metadata so, for example, there could be a [wheel] section in METADATA rather than a separate WHEEL file. We already have a namespace registry in the form of PyPI, so there's no reason to invent a new one, and allowing *any* PyPI distribution to add custom metadata fields without name conflicts would allow easy experimentation while still making it clear which fields are defined in PEPs and which are defined by particular projects. > I know that distutils2 have requires-dist, but for the sake of > argument pretend they don't. If there is first class support for > extending the metadata with new fields, a project could come > along, and add a requires-dist (or x-requires-dist) concept to > metadata. Tools that understand it would see that data and > be able to act on it, tools that don't understand it would simply > write it to the METADATA file incase in the future a tool that > does understand it needs to act on it. > > Essentially first class support for extending the metadata outside > of a PEP process means that outside of the stdlib people can > experiment and try new things, existing tools will continue to work > and just ignore that extra data (but leave it intact), new tools will be > able to utilize it to do something useful. Ideally as a new concept is > tested externally and begins to gain acceptance a new metadata > version could be created that standardizes that field as part of the > spec instead of an extension. Agreed, and this is the kind of thing a v1.3 metadata PEP could define. It just needs to be properly namespaced, and the obvious namespacing mechanism is PyPI project names. 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
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
On Tue, Aug 28, 2012 at 8:28 AM, Nick Coghlan wrote: > On Tue, Aug 28, 2012 at 10:07 PM, Donald Stufft > wrote: >> I personally think that at a minimum we should have X-Fields that >> get moved into the normal METADATA file, and personally I would >> prefer to just drop the X- prefix completely. > > Hell no. We've been down this road with setuptools and it *sucks*. > Everybody gets confused, because you can't tell just by looking at a > metadata file what's part of the standard and what's been added just > because a tool developer thought it was a good idea without being able > to obtain broad consensus (perhaps because others couldn't see the > point until the extension had been field tested for an extended > period). > > Almost *nobody* reads metadata specs other than the people that helped > write them. Everyone else copies a file that works, and tweaks it to > suit, or they use a tool that generates the metadata for them based on > some other interface. > > The least-awful widespread extension approach I'm aware of is CSS > vendor prefixes. X- headers suck because they only give you two > namespaces - the "standard" namespace and the "extension" namespace. > That means everyone is quickly forced back into seeking agreement and > consensus to avoid naming conflicts for extension fields. > > However, I'm open to the idea of a properly namespaced extension > mechanism, which is exactly why I suggested separate files flagged in > the main metadata with the PyPI project that defines the format of > those extensions. I'm also open to the idea of extensions appearing in > [PyPI distribution] prefixed sections after the standard metadata so, > for example, there could be a [wheel] section in METADATA rather than > a separate WHEEL file. > > We already have a namespace registry in the form of PyPI, so there's > no reason to invent a new one, and allowing *any* PyPI distribution to > add custom metadata fields without name conflicts would allow easy > experimentation while still making it clear which fields are defined > in PEPs and which are defined by particular projects. > > >> I know that distutils2 have requires-dist, but for the sake of >> argument pretend they don't. If there is first class support for >> extending the metadata with new fields, a project could come >> along, and add a requires-dist (or x-requires-dist) concept to >> metadata. Tools that understand it would see that data and >> be able to act on it, tools that don't understand it would simply >> write it to the METADATA file incase in the future a tool that >> does understand it needs to act on it. >> >> Essentially first class support for extending the metadata outside >> of a PEP process means that outside of the stdlib people can >> experiment and try new things, existing tools will continue to work >> and just ignore that extra data (but leave it intact), new tools will be >> able to utilize it to do something useful. Ideally as a new concept is >> tested externally and begins to gain acceptance a new metadata >> version could be created that standardizes that field as part of the >> spec instead of an extension. > > Agreed, and this is the kind of thing a v1.3 metadata PEP could > define. It just needs to be properly namespaced, and the obvious > namespacing mechanism is PyPI project names. > > Cheers, > Nick. Wheel deals with this somewhat by including a Packager: bdist_wheel line in WHEEL so that you can deal with packager-specific bugs. Bento uses indentation so you can have sections: Key: value Indented Key: value ___ 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 10:28 PM, Daniel Holth wrote: > That is my preference as well. The standard library basically ignores > every metadata field or metadata file inside or outside of metadata > currently, so where is the harm changing the official document to read > "you may add new metadata fields to metadata" with an updated standard > library that only ignores some of the metadata in metadata instead of > all of it. The community is small enough to handle it. I will campaign ardently against any such proposal. Any extension field must be clearly traceable to an authority that gets to define what it means to avoid a repeat of the setuptools debacle. Namespaces are a honkin' great idea, let's do more of those :P 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
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
How about Extensions are fields that start with a pypi-registered name followed by a hyphen. A file that contains extension fields declares them with Extension: name : Extension: pypiname pypiname-Field: value ___ 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 10:33 PM, Daniel Holth wrote: > Wheel deals with this somewhat by including a > > Packager: bdist_wheel > > line in WHEEL so that you can deal with packager-specific bugs. Right, but the problem with that is it's defining a couple of *new* namespaces to manage: - the filenames within dist_info (although uppercasing a PyPI project name is pretty safe) - the "Packager" field (bdist_wheel is a distutils command rather than a PyPI project) By using PyPI distribution names to indicate custom sections in the main metadata file, we would get to exploit an existing registry that enforces uniqueness without imposing significant overhead. > Bento uses indentation so you can have sections: > > Key: value >Indented Key: value Yes, the main metadata file could definitely go that way. The three main ways I can see an extensible metadata format working are: 1. The way wheel currently works (separate WHEEL file, naming conflicts resolved largely by first-in-first-served with no official registry, no obvious indication which project defines the format) 2. PyPI as extension registry, with an ini-file inspired section syntax inside dist-info/METADATA [wheel] Version: 0.9 Packager: bdist_wheel-0.1 Root-Is-Purelib: true 3. PyPI as extension registry, with an indented section syntax inside dist-info/METADATA Extended-Metadata: wheel Version: 0.9 Packager: bdist_wheel-0.1 Root-Is-Purelib: true My preference is currently for the ini-style variant, but I could definitely live with the indented approach.Either way, any project registered on PyPI would be free to add their own extensions without fear of naming conflicts or any doubts about the relevant authority for the meaning of the fields. Standard tools could just treat those sections as opaque blocks of text to be preserved verbatim, or else they could be constrained so that the standard tools could pick out the individual key:value pairs. Namespacing an extension mechanism based on PyPI distributions names should be pretty straightforward and it will mean that a lot of problems that can otherwise arise with extensible metadata systems should simply never come up. 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
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
On Tue, Aug 28, 2012 at 10:57 PM, Daniel Holth wrote: > How about > > Extensions are fields that start with a pypi-registered name followed > by a hyphen. A file that contains extension fields declares them with > Extension: name : > > Extension: pypiname > pypiname-Field: value The repetition seems rather annoying. Compare the two section based variants I just posted to: Extension: wheel wheel-Version: 0.9 wheel-Packager: bdist_wheel-0.1 wheel-Root-Is-Purelib: true It does have the advantage that tools for manipulating the format can remain dumber, but that doesn't seem like *that* much of an advantage, especially since any such benefit could be eliminated completely by just switching to a completely standard ConfigParser format by putting the PEP defined settings into a [python] section. 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
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
On Tuesday, August 28, 2012 at 8:28 AM, Nick Coghlan wrote: > > Agreed, and this is the kind of thing a v1.3 metadata PEP could > define. It just needs to be properly namespaced, and the obvious > namespacing mechanism is PyPI project names. The biggest reason I have against namespacing them is it makes moving from experimental to standard easier, but I'm ok with some form of a namespace. The biggest reason I see against using PyPI names as the namespace is it needlessly ties a piece of data to the original creator. Similar to how right now you could write a less hacky setuptools, but in order to do so you need to continue to use the setuptools package name (see distribute). Using PyPI names means that in the requires-dist example it would be something like setuptools-requires-dist, and even if I make my own tool that supports the same concept as setuptools's requires-dist I would need to use setuptools-requires-dist. The concept of metadata I think should be divorced from specific implementations. Obviously there are going to be some implementation specific issues but I think it's much cleaner to have a x-requires-dist that any implementation can use than to have whoever-invented-it-first-requires-dist or a twenty-different-forms-of-requires-dist. ___ 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 Tuesday, August 28, 2012 at 9:09 AM, Nick Coghlan wrote: > On Tue, Aug 28, 2012 at 10:57 PM, Daniel Holth (mailto:[email protected])> wrote: > > How about > > > > Extensions are fields that start with a pypi-registered name followed > > by a hyphen. A file that contains extension fields declares them with > > Extension: name : > > > > Extension: pypiname > > pypiname-Field: value > > > > > The repetition seems rather annoying. Compare the two section based > variants I just posted to: > > Extension: wheel > wheel-Version: 0.9 > wheel-Packager: bdist_wheel-0.1 > wheel-Root-Is-Purelib: true > > It does have the advantage that tools for manipulating the format can > remain dumber, but that doesn't seem like *that* much of an advantage, > especially since any such benefit could be eliminated completely by > just switching to a completely standard ConfigParser format by putting > the PEP defined settings into a [python] section. > METADATA files are not ini files. ___ 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 9:09 AM, Nick Coghlan wrote: > On Tue, Aug 28, 2012 at 10:57 PM, Daniel Holth wrote: >> How about >> >> Extensions are fields that start with a pypi-registered name followed >> by a hyphen. A file that contains extension fields declares them with >> Extension: name : >> >> Extension: pypiname >> pypiname-Field: value > > The repetition seems rather annoying. Compare the two section based > variants I just posted to: > > Extension: wheel > wheel-Version: 0.9 > wheel-Packager: bdist_wheel-0.1 > wheel-Root-Is-Purelib: true > > It does have the advantage that tools for manipulating the format can > remain dumber, but that doesn't seem like *that* much of an advantage, > especially since any such benefit could be eliminated completely by > just switching to a completely standard ConfigParser format by putting > the PEP defined settings into a [python] section. Wheel is a little different because once it's installed it is no longer a wheel, but it makes a decent example. That's not even repetition, it's just longer tag names. Repetition is having one Classifier: line for every trove classifier. It would be quite inconvenient to change the parser for PKG-INFO. It's a win to keep the file flat. ___ 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 Tuesday, August 28, 2012 at 9:09 AM, Nick Coghlan wrote: > > It does have the advantage that tools for manipulating the format can > remain dumber, but that doesn't seem like *that* much of an advantage, > especially since any such benefit could be eliminated completely by > just switching to a completely standard ConfigParser format by putting > the PEP defined settings into a [python] section. > To be more specific, there is setup.cfg (which I dislike for other reasons), and then there is METADATA. setup.cfg is an ini file but METADATA is a simple key: value file with a flat namespace so any namespacing you want to do in METADATA needs to be done at the key level. You could translate: [setuptools] requires-dist=foo in a setup.cfg into setuptools-requires-dist: foo in METADATA, but I'm not sure if that would be beneficial or 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] Edits to Metadata 1.2 to add extras (optional dependencies)
On Tue, Aug 28, 2012 at 11:20 PM, Daniel Holth wrote: > Wheel is a little different because once it's installed it is no > longer a wheel, but it makes a decent example. That's not even > repetition, it's just longer tag names. Repetition is having one > Classifier: line for every trove classifier. > > It would be quite inconvenient to change the parser for PKG-INFO. It's > a win to keep the file flat. Cool, it's the namespace I care about. Every piece of extended metadata must have an authority who gets to define what it means. If that means people register a "virtual" PyPI project just to reserve an extension namespace, I'm fine with that. 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
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
On Tue, Aug 28, 2012 at 11:23 PM, Donald Stufft wrote: > To be more specific, there is setup.cfg (which I dislike for other reasons), > and > then there is METADATA. setup.cfg is an ini file but METADATA is a simple > key: value file with a flat namespace so any namespacing you want to do in > METADATA needs to be done at the key level. We're talking about the format for v1.3 of the metadata. That format is not defined yet, so it's not obligatory for it to remain a flat key value store. However, there are advantages to keeping it as such, so I'm fine with Daniel's suggested approach. The only thing I really care about is the namespacing, for the same reasons the IETF wrote RFC 6648, as Petri linked earlier [1]. Establishing proper name registration rules can categorically eliminate a bunch of problems further down the line (such as the past confusion between which metadata entries were defined by PEPs and which were setuptools-specific extensions that other tools might not understand). With PyPI based namespacing we get clear orthogonal naming with clear lines of authority: 1. PEPs continue to define the core metadata used by PyPI, the standard library (once we get updated packaging support in place) and most other tools 2. Any members of the community with a specific interest can register a PyPI project to define additional metadata without risking naming conflicts. This need may arise in the context of a specific project, and thus use that project's name, or else it may be a project registered for the express purpose of being a metadata namespace, and not actually correspond to any installable module. The main point is to take advantage of an existing automated Python-specific name and resource registry to avoid naming conflicts without Java-style reverse DNS based clutter, and without python-dev having to explicitly approve each and every metadata extension. Cheers, Nick. [1] https://tools.ietf.org/html/rfc6648#section-4 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
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
On Tuesday, August 28, 2012 at 9:41 AM, Nick Coghlan wrote: > > The only thing I really care about is the namespacing, for the same > reasons the IETF wrote RFC 6648, as Petri linked earlier [1]. > Establishing proper name registration rules can categorically > eliminate a bunch of problems further down the line (such as the past > confusion between which metadata entries were defined by PEPs and > which were setuptools-specific extensions that other tools might not > understand). > > I'm happy with any form of a namespace to be quite honest. I have a bit of a preference for no or flat namespace but i'm perfectly fine with a PyPI based namespace. The important part is a defined way to extend the data that even when tools don't understand the extended data they can losslessly move it around from setup.cfg/setup.py/whatever to METADATA and any other format, even if they themselves don't utilize it, leaving it intact for tools that _do_ utilize it. ___ 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 11:48 PM, Donald Stufft wrote: > On Tuesday, August 28, 2012 at 9:41 AM, Nick Coghlan wrote: > > The only thing I really care about is the namespacing, for the same > reasons the IETF wrote RFC 6648, as Petri linked earlier [1]. > Establishing proper name registration rules can categorically > eliminate a bunch of problems further down the line (such as the past > confusion between which metadata entries were defined by PEPs and > which were setuptools-specific extensions that other tools might not > understand). > > > I'm happy with any form of a namespace to be quite honest. I have a bit of > a preference for no or flat namespace but i'm perfectly fine with a PyPI > based > namespace. The important part is a defined way to extend the data that > even when tools don't understand the extended data they can losslessly > move it around from setup.cfg/setup.py/whatever to METADATA and > any other format, even if they themselves don't utilize it, leaving it > intact > for tools that _do_ utilize it. Oh, yes, I care about that part, too, as without that there's no reason to define a metadata extension format at all :) 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
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
Am 28.08.12 14:28, schrieb Daniel Holth: On Tue, Aug 28, 2012 at 8:07 AM, Donald Stufft wrote: I personally think that at a minimum we should have X-Fields that get moved into the normal METADATA file, and personally I would prefer to just drop the X- prefix completely. That is my preference as well. The standard library basically ignores every metadata field or metadata file inside or outside of metadata currently, so where is the harm changing the official document to read "you may add new metadata fields to metadata" with an updated standard library that only ignores some of the metadata in metadata instead of all of it. The community is small enough to handle it. The problem with that (and the reason to introduce the X- prefix in RFC 822) is that allowing arbitrary additions will make evolution difficult: if you want to standardize a certain field at some point, you either need to pick a name that is unused in all implementations (which you never can be really certain about), or you break some existing tool by making the addition (unless the addition happens to have the exact same syntax and semantics as the prior use). 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)
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? I'm happy for PyPI to host such a registry. A specificaion for the registry should be part of the PEP for the 1.3 format, but I would propose this structure (without having researched in detail what other registries feature, but with a rough idea what IANA registries typically include): - name of metadata field - name of registrant (individual or PyPI package) - contact email address (published) - expiration date; by default, extensions expire 1 month after their registration, unless renewed; maximum expiration time is 5 years - English description of the field - regular expression to validate the field Deleting undesired extensions would not be possible, instead, one would have to create another extension if the syntax or semantics changes 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)
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. Maybe I misphrased. By "accepted" I meant "widely implemented". From the day this gets published until it is really usable, I still believe 10 years is realistic. For example, setuptools doesn't implement Meta-data 1.2, and nearly nobody uses it, 8 years after it was written. 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. The problem is that flooding people with specifications is a guarantee that they will not get implemented. So we can have one metadata specification every ten years; if we have more, none of them will be implemented (except in the tool of the author of 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 Tuesday, August 28, 2012 at 10:43 AM, "Martin v. Löwis" wrote: > > I'm happy for PyPI to host such a registry. A specificaion for the > registry should be part of the PEP for the 1.3 format, but I would > propose this structure (without having researched in detail what > other registries feature, but with a rough idea what IANA registries > typically include): PyPI packages itself could serve as a registry, but I like the idea of a separate registry better in many ways because it lets you divorce the namespace from the package. The question being would this be a x-registered-name type system or a registered-namespace-* type system? It occurs to me one problem with arbitrary namespaces is there is a unintended collision problem. e.g. you have the foo-bar namespace and the foo namespace, what happens if you have a test key inside of foo-bar and a bar-test inside of the foo namepspace. They'll both end up being foo-bar-test. This makes me think that we need a seperate registry and that if we go the namespace route it should be limited to alphanumerics only so that you don't have the foo/foo-bar collision problem. > > - name of metadata field > - name of registrant (individual or PyPI package) > - contact email address (published) > - expiration date; by default, extensions expire 1 month after > their registration, unless renewed; maximum expiration time is > 5 years > - English description of the field > - regular expression to validate the field What happens when it expires? Is that name freed up for future use? I think that freeing up the name is likely to be a bad idea since we can't go backwards in time (as you alluded to later about not deleting them), so what does expiration do? > > Deleting undesired extensions would not be possible, instead, one > would have to create another extension if the syntax or semantics > changes ___ 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
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? This is the standard for any security fix: such a fix would be added to 3.1.6, 3.2.4, 3.3.1, and 3.4.0, but not to 3.2.3 or 3.3.0. So version(A) > version(B) does not imply has_fix(A, F) if has_fix(B, F) (for Python releases A and B and fix F) The same would regularly happen with any bug fix, too, except we only have one bug fix branch at nearly every point in time (except that we have the 2.7 branch as well). Regards, Martin P.S. Python 3.1 will continue to receive security fixes until June 2014, 3.2 will receive them until February 2016, 3.3 until September 2017. For 2.7, a policy needs to be set after the last bug fix release of 2.7 was made. ___ 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 Wed, Aug 29, 2012 at 12:53 AM, Donald Stufft wrote: > On Tuesday, August 28, 2012 at 10:43 AM, "Martin v. Löwis" wrote: > > I'm happy for PyPI to host such a registry. A specificaion for the > registry should be part of the PEP for the 1.3 format, but I would > propose this structure (without having researched in detail what > other registries feature, but with a rough idea what IANA registries > typically include): > > PyPI packages itself could serve as a registry, but I like the idea of > a separate registry better in many ways because it lets you divorce > the namespace from the package. The question being would this > be a x-registered-name type system or a registered-namespace-* > type system? Please, don't. The software and infrastructure to run PyPI exists. Some level of namespacing makes sense to separate out extension management to different groups of people, but creating a whole management application just for this would be serious overkill. 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
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
Am 28.08.12 16:53, schrieb Donald Stufft: On Tuesday, August 28, 2012 at 10:43 AM, "Martin v. Löwis" wrote: I'm happy for PyPI to host such a registry. A specificaion for the registry should be part of the PEP for the 1.3 format, but I would propose this structure (without having researched in detail what other registries feature, but with a rough idea what IANA registries typically include): PyPI packages itself could serve as a registry, but I like the idea of a separate registry better in many ways because it lets you divorce the namespace from the package. Maybe I didn't express myself clearly - this is exactly what I proposed. The registry would be implemented in the same software as PyPI, and run on the same machine, and (perhaps) have pypi.python.org as it's domain name, but otherwise would be decoupled from Python packages. What happens when it expires? Is that name freed up for future use? Yes, exactly. I think that freeing up the name is likely to be a bad idea since we can't go backwards in time (as you alluded to later about not deleting them), so what does expiration do? Why would it require going backwards in time? Existing usages of the extension just become invalid, e.g. with the consequence that you can't upload the package to PyPI anymore unless you remove the extension, or re-register it. If the extension is in active use, somebody certainly will make sure it stays registered. Expiration is to free up names that are not in active use, but are otherwise reasonable names for metadata fields (say, Requires-Unicode-Version). 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 Tuesday, August 28, 2012 at 11:05 AM, Nick Coghlan wrote: > On Wed, Aug 29, 2012 at 12:53 AM, Donald Stufft (mailto:[email protected])> wrote: > > Please, don't. The software and infrastructure to run PyPI exists. > Some level of namespacing makes sense to separate out extension > management to different groups of people, but creating a whole > management application just for this would be serious overkill. > How do you deal with a PyPI package foo which wants a bar-test value (foo-bar-test), and a PyPI package foo-bar with a value test (foo-bar-test). PyPI packages allow too much in the way of names to be able to fully namespace it without collisions. ___ 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 Tuesday, August 28, 2012 at 11:07 AM, "Martin v. Löwis" wrote: > > What happens when it expires? Is that name freed up for future use? > > > Yes, exactly. > > > I > > think that freeing up the name is likely to be a bad idea since we can't go > > backwards in time (as you alluded to later about not deleting them), so > > what does expiration do? > > > > > Why would it require going backwards in time? Existing usages of the > extension just become invalid, e.g. with the consequence that you can't > upload the package to PyPI anymore unless you remove the extension, > or re-register it. > > If the extension is in active use, somebody certainly will make sure it > stays registered. Expiration is to free up names that are not in active > use, but are otherwise reasonable names for metadata fields (say, > Requires-Unicode-Version). What do you do with packages that have already been uploaded with requires-unicode-version once it expires? If the point of a registry is to remove ambiguity from what any particular key means, won't expiring and allowing reregistration of an in use name (even if it's no longer being uploaded, but is still available inside of a package) reintroduce that same ambiguity? How will we know that requires-unicode-version from a package uploaded a year ago and has since expired is different than requires-unicode-version from a package uploaded yesterday and has been reregistered? ___ 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 10:47 AM, "Martin v. Löwis" wrote: >>> 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. > > > Maybe I misphrased. By "accepted" I meant "widely implemented". From > the day this gets published until it is really usable, I still believe > 10 years is realistic. For example, setuptools doesn't implement Meta-data > 1.2, and nearly nobody uses it, 8 years after it was written. > >> 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. > > > The problem is that flooding people with specifications is a guarantee > that they will not get implemented. So we can have one metadata > specification every ten years; if we have more, none of them will be > implemented (except in the tool of the author of the PEP). Why not. You get the feature in the tool, and you don't get it elsewhere, but the other implementation can still parse what it understands. The tool author promotes his tool for this reason. The extension format is intentionally ugly so that people will standardize eventually if only for aesthetic reasons. Yes, you have to support popular extensions forever, it's a messy world we live in. Two tools that implement Metadata 1.2+ are called wheel and distribute >= 0.6.28. It's just adding the requirements in PKG-INFO (METADATA) instead of in a separate .txt file. Unfortunately it was necessary to add Setup-Requires-Dist:, Provides-Extra: and an extra variable in the conditional-dependencies (environment markers) spec to be able to represent setuptools data present in 10% of the packages on PyPi. So it is necessary to edit the PEP for the environment markers, but Provides-Extra could change to Extension: distribute Distribute-Provides-Extra: foo (Just require un-hyphenated names in Extension: or map them to underscore _ if you must) -1 on doing anything but mapping them to package names. I can't provide a regex to strictly validate Requires-Dist: foo ; condition because condition is an impoverished subset of the Python language filtered with the wonderful ast module. Are you really willing to unpack and validate PKG-INFO on every archive that is uploaded to pypi? ___ 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, 28 Aug 2012 11:17:08 -0400, Donald Stufft wrote: > On Tuesday, August 28, 2012 at 11:07 AM, "Martin v. Löwis" wrote: > > > > What happens when it expires? Is that name freed up for future use? > > > > > > Yes, exactly. > > > > > I > > > think that freeing up the name is likely to be a bad idea since we can't > > > go > > > backwards in time (as you alluded to later about not deleting them), so > > > what does expiration do? > > > > > > > > > Why would it require going backwards in time? Existing usages of the > > extension just become invalid, e.g. with the consequence that you can't > > upload the package to PyPI anymore unless you remove the extension, > > or re-register it. > > > > If the extension is in active use, somebody certainly will make sure it > > stays registered. Expiration is to free up names that are not in active > > use, but are otherwise reasonable names for metadata fields (say, > > Requires-Unicode-Version). > > What do you do with packages that have already been uploaded with > requires-unicode-version once it expires? If the point of a registry is > to remove ambiguity from what any particular key means, won't expiring > and allowing reregistration of an in use name (even if it's no longer being > uploaded, but is still available inside of a package) reintroduce that same > ambiguity? How will we know that requires-unicode-version from a package > uploaded a year ago and has since expired is different than > requires-unicode-version > from a package uploaded yesterday and has been reregistered? Ah, that's a better phrasing of the same concern I had but couldn't figure out how to articulate. I don't recall any RFC registries that have expiration dates for entries. Are there any? RFC registries usually have an organization vetting the entries, whereas it seems like we want this to be an open registry. Note that the MIME-type specification allows for "vendor types", which is a namespace mechanism and allows delegation of vetting authority. That sounds more like Nick's proposal. (I'm sure there is some way to solve the ambiguity issue.) We could still have a (vetted) registry for "official" names, if we wanted. That would follow the MIME model. Or we can still have a separate registry, but only "qualified" (namespaced) names are open for anyone to register, without any expiration dates. -- R. David Murray If you like the work I do for Python, you can enable me to spend more time doing it by supporting me here: http://gittip.com/bitdancer ___ 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 28.08.12 17:17, schrieb Donald Stufft: What do you do with packages that have already been uploaded with requires-unicode-version once it expires? Who is "I" in this case? The PyPI installation? Mark the keys in the database as expired, and stop displaying them. If the key is restored, and the values are still syntactically correct, restore the values. Or is "I" software which downloads packages? Continue doing what it always does for invalid meta-data: I recommend to issue a warning; aborting the setup could also work. If the point of a registry is to remove ambiguity from what any particular key means, won't expiring and allowing reregistration of an in use name (even if it's no longer being uploaded, but is still available inside of a package) reintroduce that same ambiguity? No: if nobody renews the old registration, it's because the extension is not in use. So the case you are constructing won't happen in practice. How will we know that requires-unicode-version from a package uploaded a year ago and has since expired is different than requires-unicode-version from a package uploaded yesterday and has been reregistered? If the packages that were uploaded a year ago are still in active use, somebody will renew the registration. So the case won't happen. If nobody cares about the specific field, it may break, which is then well-deserved. 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 Tue, 28 Aug 2012 18:08:51 +0200, =?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?= wrote: > Am 28.08.12 17:17, schrieb Donald Stufft: > > If the point of a registry is > > to remove ambiguity from what any particular key means, won't expiring > > and allowing reregistration of an in use name (even if it's no longer being > > uploaded, but is still available inside of a package) reintroduce that same > > ambiguity? > > No: if nobody renews the old registration, it's because the extension is > not in use. So the case you are constructing won't happen in practice. > > > How will we know that requires-unicode-version from a package > > uploaded a year ago and has since expired is different than > > requires-unicode-version > > from a package uploaded yesterday and has been reregistered? > > If the packages that were uploaded a year ago are still in active use, > somebody will renew the registration. So the case won't happen. > > If nobody cares about the specific field, it may break, which is > then well-deserved. The problem Donald is asking about is: the old registration expires, and a *new* registration is entered with a different meaning, but packages still exist on PyPI that have the key with the old meaning. That seems likely to happen in practice. Or if it doesn't, then allowing for the recycling of names probably isn't important. -- R. David Murray If you like the work I do for Python, you can enable me to spend more time doing it by supporting me here: http://gittip.com/bitdancer ___ 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 28.08.12 17:38, schrieb R. David Murray: I don't recall any RFC registries that have expiration dates for entries. Are there any? The RFC database itself has expiration dates on specifications, namely on I-D documents (internet drafts). The expire 6 months after their initial publication, unless renewed. For number assignments, the risk is that it will eventually run out of numbers, in which case the protocol gets redesigned to increase the number space. For name assignments, the risk is that many similar-sounding elements become used, and people accept that as a trade-off for the problems you see in my expiration proposal. The most popular name registry that does have expiration (despite being hierarchical) is the DNS: you have to renew your names yearly in most TLDs. People apparently accept the risk of confusion when a domain expires and gets reused by someone else (and yes, the DNS *is* an "RFC registry" :-) RFC registries usually have an organization vetting the entries, whereas it seems like we want this to be an open registry. It very much depends. If you browse over the IANA registries, you find that many parameter space require "IETF consensus", so they can be extended only by RFC (similar to the status quo in metadata). There are IANA registries that are open (e.g. SNMP, or MIME); things are assigned in a first-come first-served manner (e.g. try to find out what 1.3.6.1.4.1.18832.11.3 is :-) We could still have a (vetted) registry for "official" names, if we wanted. That would follow the MIME model. Or we can still have a separate registry, but only "qualified" (namespaced) names are open for anyone to register, without any expiration dates. I don't consider it an absolute necessity that there is an expiration. I do consider it a flaw in (some) IANA name registrations that there is no expiration to them; I can report that people regularly want to claim some PyPI package name on the basis that the original owner didn't ever release any software under that name. 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)
Am 28.08.12 18:27, schrieb R. David Murray: > The problem Donald is asking about is: the old registration expires, > and a *new* registration is entered with a different meaning, but > packages still exist on PyPI that have the key with the old meaning. > That seems likely to happen in practice. Or if it doesn't, then > allowing for the recycling of names probably isn't important. Let me retry answering the question: Expiration *is* important in the case the key was just registered and never used, because it may be a good name for something, but can't be used because it is reserved for a use case that has no users. If the key is *widely* used, the scenario you assume is *not* likely in practice - either the original registrant will renew the registration before it expires, or somebody else will reregister it after it expires. There is also the case of a key that is used in a few packages (one or two packages seems a likely case - namely packages produced by the original registrant for the purpose of testing). Assuming the registrant then loses interest, and nobody else starts using the keys (i.e. they are not widely used), then these packages will break (in a mode that can be painted in different colors). This may happen, but I don't consider it a problem. If the original author finds the package broken, he will have to release a new version without the these keys, or re-register them under a new name (since his original name is now taken by somebody else - who hopefully can attract more users with his definition of the key). There is also the potential risk of key-jacking, which can be resolved administratively (by revoking the abusive registration). 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)
Am 28.08.12 17:30, schrieb Daniel Holth: > Are you really willing to unpack and validate PKG-INFO on every > archive that is uploaded to pypi? Users should run the "register" command, which will provide the metadata information. Also, the UI needs to be extended to allow to fill out and edit metadata information interactively, or upload it. And yes, PyPI already extracts (but currently doesn't further process) PKG-INFO from every archive that is uploaded. So PyPI absolutely needs to "know" about the meta-data. 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 Tue, 28 Aug 2012 18:47:16 +0200, =?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?= wrote: > Am 28.08.12 18:27, schrieb R. David Murray: > > The problem Donald is asking about is: the old registration expires, > > and a *new* registration is entered with a different meaning, but > > packages still exist on PyPI that have the key with the old meaning. > > That seems likely to happen in practice. Or if it doesn't, then > > allowing for the recycling of names probably isn't important. > > Let me retry answering the question: Expiration *is* important in > the case the key was just registered and never used, because it may > be a good name for something, but can't be used because it is reserved > for a use case that has no users. > > If the key is *widely* used, the scenario you assume is *not* likely > in practice - either the original registrant will renew the registration > before it expires, or somebody else will reregister it after it expires. > > There is also the case of a key that is used in a few packages (one > or two packages seems a likely case - namely packages produced by the > original registrant for the purpose of testing). Assuming the registrant > then loses interest, and nobody else starts using the keys (i.e. they > are not widely used), then these packages will break (in a mode that > can be painted in different colors). This may happen, but I don't > consider it a problem. If the original author finds the package broken, > he will have to release a new version without the these keys, or > re-register them under a new name (since his original name is now > taken by somebody else - who hopefully can attract more users with > his definition of the key). > > There is also the potential risk of key-jacking, which can be > resolved administratively (by revoking the abusive registration). OK, I understand your logic now. Yes that does make sense to me. There are tradeoffs to be made, and this seems like a reasonable tradeoff given the goals articulated so far. -- R. David Murray If you like the work I do for Python, you can enable me to spend more time doing it by supporting me here: http://gittip.com/bitdancer ___ 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 06:36:40PM +0200, "\"Martin v. L?wis\"" wrote: > Am 28.08.12 17:38, schrieb R. David Murray: > >I don't recall any RFC registries that have expiration dates for > >entries. Are there any? > > The RFC database itself has expiration dates on specifications, > namely on I-D documents (internet drafts). The expire 6 months > after their initial publication, unless renewed. Does that expiration mean something? The draft for Web Proxy Autodiscovery Protocol[1] expired in 1999 but still is widely implemented and used. 1. https://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ 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 28.08.12 19:15, schrieb Oleg Broytman: >> The RFC database itself has expiration dates on specifications, >> namely on I-D documents (internet drafts). The expire 6 months >> after their initial publication, unless renewed. > > Does that expiration mean something? It's explained in RFC 2026. An internet draft is not an internet standard, it may get changed at any time. An I-D which is expired and still used has the same relevance as a proprietary standard; it has nothing to do with the internet standards process. Whether this has any practical consequence depends on the market, of course. Customers that insist on standards compliance will look for RFC compliance, but typically not for I-D compliance. If the field of standardization is of relevance for such users, they will eventually ask for an RFC to be issued, which then may or may not be compatible with a long-standing proprietary standard. 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 Tue, Aug 28, 2012 at 08:19:08PM +0200, "\"Martin v. L?wis\"" wrote: > Am 28.08.12 19:15, schrieb Oleg Broytman: > >> The RFC database itself has expiration dates on specifications, > >> namely on I-D documents (internet drafts). The expire 6 months > >> after their initial publication, unless renewed. > > > > Does that expiration mean something? > > It's explained in RFC 2026. An internet draft is not an internet > standard, it may get changed at any time. An I-D which is expired > and still used has the same relevance as a proprietary standard; > it has nothing to do with the internet standards process. > > Whether this has any practical consequence depends on the market, > of course. Customers that insist on standards compliance will look > for RFC compliance, but typically not for I-D compliance. If the > field of standardization is of relevance for such users, they will > eventually ask for an RFC to be issued, which then may or may not > be compatible with a long-standing proprietary standard. I see. Thank you! Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ 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] [Python-checkins] cpython: Issue #15794: Relax a test case due to the deadlock detection's
Should there be a Misc/NEWS entry since we are in rc mode? On Tue, Aug 28, 2012 at 2:13 PM, antoine.pitrou wrote: > http://hg.python.org/cpython/rev/454dceb5fd56 > changeset: 78790:454dceb5fd56 > parent: 78788:06497bbdf4fe > user:Antoine Pitrou > date:Tue Aug 28 20:10:18 2012 +0200 > summary: > Issue #15794: Relax a test case due to the deadlock detection's > conservativeness. > > files: > Lib/test/test_importlib/test_locks.py | 22 -- > 1 files changed, 18 insertions(+), 4 deletions(-) > > > diff --git a/Lib/test/test_importlib/test_locks.py > b/Lib/test/test_importlib/test_locks.py > --- a/Lib/test/test_importlib/test_locks.py > +++ b/Lib/test/test_importlib/test_locks.py > @@ -1,4 +1,5 @@ > from importlib import _bootstrap > +import sys > import time > import unittest > import weakref > @@ -41,6 +42,17 @@ > @unittest.skipUnless(threading, "threads needed for this test") > class DeadlockAvoidanceTests(unittest.TestCase): > > +def setUp(self): > +try: > +self.old_switchinterval = sys.getswitchinterval() > +sys.setswitchinterval(0.01) > +except AttributeError: > +self.old_switchinterval = None > + > +def tearDown(self): > +if self.old_switchinterval is not None: > +sys.setswitchinterval(self.old_switchinterval) > + > def run_deadlock_avoidance_test(self, create_deadlock): > NLOCKS = 10 > locks = [LockType(str(i)) for i in range(NLOCKS)] > @@ -75,10 +87,12 @@ > > def test_deadlock(self): > results = self.run_deadlock_avoidance_test(True) > -# One of the threads detected a potential deadlock on its second > -# acquire() call. > -self.assertEqual(results.count((True, False)), 1) > -self.assertEqual(results.count((True, True)), len(results) - 1) > +# At least one of the threads detected a potential deadlock on its > +# second acquire() call. It may be several of them, because the > +# deadlock avoidance mechanism is conservative. > +nb_deadlocks = results.count((True, False)) > +self.assertGreaterEqual(nb_deadlocks, 1) > +self.assertEqual(results.count((True, True)), len(results) - > nb_deadlocks) > > def test_no_deadlock(self): > results = self.run_deadlock_avoidance_test(False) > > -- > Repository URL: http://hg.python.org/cpython > > ___ > Python-checkins mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-checkins > > ___ 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] cpython: Issue #15794: Relax a test case due to the deadlock detection's
On Tue, 28 Aug 2012 15:00:57 -0400 Brett Cannon wrote: > Should there be a Misc/NEWS entry since we are in rc mode? Well, I didn't ask for 3.3.0 inclusion, since this is a very minor fix. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ 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] core dev IRC nicks
Is there a list somewhere of the IRC nicks of the core developers that use IRC (and who wish to be listed) alongside their real names? If there is no such list, has there ever been discussion on python-dev of creating such a list? --Chris ___ 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] Copyediting PEPs
What's the procedure for making trivial edits to a PEP? I was (re)reading PEP 393 and found a couple of typos (PyCompactObject s/be PyCompactUnicodeObject and "differs form length" s/be "from"). Can I edit them directly in the web site's SVN repo, or should a patch be submitted? Apologies for the perhaps clueless question! ChrisA ___ 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] core dev IRC nicks
On Tue, Aug 28, 2012 at 10:58 PM, Chris Jerdonek wrote: > Is there a list somewhere of the IRC nicks of the core developers that > use IRC (and who wish to be listed) alongside their real names? If > there is no such list, has there ever been discussion on python-dev of > creating such a list? I'm sure we could make one, but it's probably of limited utility since not many people are on IRC, and those who are come and go throughout the day, throughout the month, year, etc. It'd just end up being another list to try and keep up to date (alphabetized, of course). You're probably better off just asking who's around whenever you're on. ___ 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] core dev IRC nicks
On Wed, Aug 29, 2012 at 1:58 PM, Chris Jerdonek wrote: > Is there a list somewhere of the IRC nicks of the core developers that > use IRC (and who wish to be listed) alongside their real names? If > there is no such list, has there ever been discussion on python-dev of > creating such a list? No, to all those questions. It's not a bad idea, though. One possibility (if someone was willing to work on it) would be to enhance our Roundup instance to handle it. (See http://docs.python.org/devguide/tracker.html#the-meta-tracker) Allow users to add their typical IRC handle, and perhaps add a "Committers List" link below the existing "Users List" link in the sidebar. 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
Re: [Python-Dev] Copyediting PEPs
On Wed, Aug 29, 2012 at 2:03 PM, Chris Angelico wrote: > What's the procedure for making trivial edits to a PEP? I was > (re)reading PEP 393 and found a couple of typos (PyCompactObject s/be > PyCompactUnicodeObject and "differs form length" s/be "from"). Can I > edit them directly in the web site's SVN repo, or should a patch be > submitted? > > Apologies for the perhaps clueless question! Sending a patch to the PEP editors ([email protected]) or posting it to the tracker is likely the best option. However, in the general case, we don't worry too much about minor errors in accepted and final PEPs - once the PEP is implemented, they're mostly historical records rather than reference documents (some exceptions do exist, but those mostly related to items that weren't properly documented in the language and library reference. The two most notable offenders, PEP 302 and 3118, have finally been replaced by more comprehensive documentation for the import system and binary buffer protocol in the official docs for 3.3) 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
Re: [Python-Dev] Copyediting PEPs
On Wed, Aug 29, 2012 at 2:36 PM, Nick Coghlan wrote: > Sending a patch to the PEP editors ([email protected]) or posting it to > the tracker is likely the best option. However, in the general case, > we don't worry too much about minor errors in accepted and final PEPs > - once the PEP is implemented, they're mostly historical records > rather than reference documents Thanks. I'll not worry about it then; PEP 393 is final. ChrisA ___ 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] Copyediting PEPs
Hm. I would be fine with the edits proposed, no need to bother others. But please do use the Hg repo. :-) On Tuesday, August 28, 2012, Chris Angelico wrote: > On Wed, Aug 29, 2012 at 2:36 PM, Nick Coghlan > > > wrote: > > Sending a patch to the PEP editors ([email protected] ) or > posting it to > > the tracker is likely the best option. However, in the general case, > > we don't worry too much about minor errors in accepted and final PEPs > > - once the PEP is implemented, they're mostly historical records > > rather than reference documents > > Thanks. I'll not worry about it then; PEP 393 is final. > > ChrisA > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- Sent from Gmail Mobile ___ 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] Copyediting PEPs
On Wed, Aug 29, 2012 at 2:45 PM, Guido van Rossum wrote: > Hm. I would be fine with the edits proposed, no need to bother others. But > please do use the Hg repo. :-) Indeed :) (Also, as described in PEP 1, any core committer can act as a PEP editor - the [email protected] address is most useful when there's no specific core developer handling updates) 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
