Proposing PEP 345 : Metadata for Python Software Packages 1.2
Hi, On behalf of the Distutils-SIG, I would like to propose to addition of PEP 345 (once and *if* PEP 386 is accepted). It's the metadata v1.2: http://www.python.org/dev/peps/pep-0345/ PEP 345 was initiated a while ago by Richard Jones, and reworked since then together with PEP 386, at Pycon last year and in Distutils-SIG. The major enhancements are: - being able to express dependencies on other *distributions* names, rather than packages names or modules names. This enhancement comes from Setuptools and has been used successfully for years by the community. - being able to express some fields which values are specific to some platforms. For example, being able to define "pywin32" as a dependency *only* on win32. This enhancement will allow any tool to query PyPI and to get the metadata for a particular execution context, without having to download, build, or install the project itself. - being able to provide a list of browsable URLs for the project, like a bug tracker, a repository etc, in addition to the home url. This will allow UIs like PyPI to display a list of URLs for a project. A side-effect will be that a project maintainer will be able to drive its end users to the right places when they need to find detailed documentation or provide some feedback. This enhancement was driven by the discussions about the rating/comment system at PyPI on catalog-sig. We believe that having PEP 386 and PEP 345 accepted will be a major improvement for the Python packaging eco-system. The next PEP in the series we are working on is PEP 376. As a side note, I would really like to see them (hopefully) accepted before the first beta of Python 2.7 so we can add these features in 2.7/3.2 and start to work on third-party tools (Distribute, Pip, a standalone version of Distutils for 2.6/2.5, etc..) to get ready to support them by the time 2.7 final is out. Regards Tarek -- Tarek Ziadé | http://ziade.org
Tarek Ziadé wrote:
Hi,
On behalf of the Distutils-SIG, I would like to propose to addition of PEP 345 (once and *if* PEP 386 is accepted).
+1 for integrating all the good work the catalog-sig folks have been doing. Some comments on PEP 345 specifically though: The deprecation of the existing Requires/Provides/Obsoletes fields should be more prominent - tucked away below the examples, I missed these notices on the first read through (I only noticed that they actually had been formally deprecated when I got to the summary of differences at the end). I suggest placing the deprecation notice immediately after the relevant field headers. There also needs to be an explanation in the PEP as to whether or not it is legal to use both Requires and Requires-Dist (etc) in the same PKG-INFO file. (i.e. what is the use case for allowing the old fields to be used in a metadata v1.2 PKG-INFO file? Should PEP 345 aware packaging tools just ignore the old fields, while v1.1 tools ignore the new ones? Or should new tools attempt to handle both?) The various lines about there being no standards or canonical definitions for particular fields also seem to run counter to the spirit of the detailed guidelines in the description of each field (which imply that some standards have already been adopted by convention). Perhaps these comments could be softened to say that although the metadata specification formally allows arbitrary strings in these fields, the descriptions are recommended guidelines for creating field entries that automated tools will handle correctly? Finally, as a general formatting request - some blank space between the end of the previous example and the header for the next field description would make the field descriptions much easier to read. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nick Coghlan wrote:
Tarek Ziadé wrote:
Hi,
On behalf of the Distutils-SIG, I would like to propose to addition of PEP 345 (once and *if* PEP 386 is accepted).
+1 for integrating all the good work the catalog-sig folks have been doing.
Some comments on PEP 345 specifically though:
The deprecation of the existing Requires/Provides/Obsoletes fields should be more prominent - tucked away below the examples, I missed these notices on the first read through (I only noticed that they actually had been formally deprecated when I got to the summary of differences at the end). I suggest placing the deprecation notice immediately after the relevant field headers.
Good point. I thought I had done so in the initial editing pass.
There also needs to be an explanation in the PEP as to whether or not it is legal to use both Requires and Requires-Dist (etc) in the same PKG-INFO file. (i.e. what is the use case for allowing the old fields to be used in a metadata v1.2 PKG-INFO file? Should PEP 345 aware packaging tools just ignore the old fields, while v1.1 tools ignore the new ones? Or should new tools attempt to handle both?)
No tools that I know of currently use 'Requires' / 'Provides' / 'Obsoletes' at all: their contents have never been informative enough to allow for useful automation. For completeness sake, we can document that tools should ignore any 'Requires', 'Provides', or 'Obsoletes' fields when any of the '-Dist' versions are present.
The various lines about there being no standards or canonical definitions for particular fields also seem to run counter to the spirit of the detailed guidelines in the description of each field (which imply that some standards have already been adopted by convention). Perhaps these comments could be softened to say that although the metadata specification formally allows arbitrary strings in these fields, the descriptions are recommended guidelines for creating field entries that automated tools will handle correctly?
That language is left over from PEP 314, which introduced those "advisory" fields. The expectation of PEP 345 is that developers who want their packages to be easily consumable by automated tools will avoid the deprecated fields and use the more usefully-specifiied new ones.
Finally, as a general formatting request - some blank space between the end of the previous example and the header for the next field description would make the field descriptions much easier to read.
Hmm, I thought we were following stock ReST formats: perhaps the CSS should be adjusted to give a larger leading space to headings? Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksxgOgACgkQ+gerLs4ltQ5VdgCgqAFmJ89DbKLw/5YFsasuU6tp HUYAoK+ek+86Xsq3oVYspEk95OkFaJjv =nWJT -----END PGP SIGNATURE-----
On Wed, Dec 23, 2009 at 3:31 AM, Tres Seaver <tseaver@palladion.com> wrote: [..]
The deprecation of the existing Requires/Provides/Obsoletes fields should be more prominent - tucked away below the examples, I missed these notices on the first read through (I only noticed that they actually had been formally deprecated when I got to the summary of differences at the end). I suggest placing the deprecation notice immediately after the relevant field headers.
Good point. I thought I had done so in the initial editing pass.
I've done it yesterday.
There also needs to be an explanation in the PEP as to whether or not it is legal to use both Requires and Requires-Dist (etc) in the same PKG-INFO file. (i.e. what is the use case for allowing the old fields to be used in a metadata v1.2 PKG-INFO file? Should PEP 345 aware packaging tools just ignore the old fields, while v1.1 tools ignore the new ones? Or should new tools attempt to handle both?)
No tools that I know of currently use 'Requires' / 'Provides' / 'Obsoletes' at all: their contents have never been informative enough to allow for useful automation. For completeness sake, we can document that tools should ignore any 'Requires', 'Provides', or 'Obsoletes' fields when any of the '-Dist' versions are present.
Although some (a small number) distributions use these, so one way to handle it is to do a little bit like what was done when 1.1 came out: if a "1.2" field is found and no "1.1" field is found: metadata 1.2 is used if a "1.1" field is found and no "1.2" field is found: metadata 1.1 is used + a warning is displayed if a "1.1" field is found and a "1.2" field is found: a warning is displayed and 1.2 is used, 1.1 fields are ignored if no 1.1 field or 1.2 fields are found: metadata 1.2 is used
The various lines about there being no standards or canonical definitions for particular fields also seem to run counter to the spirit of the detailed guidelines in the description of each field (which imply that some standards have already been adopted by convention). Perhaps these comments could be softened to say that although the metadata specification formally allows arbitrary strings in these fields, the descriptions are recommended guidelines for creating field entries that automated tools will handle correctly?
That language is left over from PEP 314, which introduced those "advisory" fields. The expectation of PEP 345 is that developers who want their packages to be easily consumable by automated tools will avoid the deprecated fields and use the more usefully-specifiied new ones.
Notice that I now provide in 2.7/3.2 a way to read *and* write PKG-INFO from an API: http://docs.python.org/dev/distutils/examples.html#reading-the-metadata meaning that whatever fields a developer use, this API will let the installers and other automated tool gets the metadata. It might be a good thing to inform about that API in the PEP I guess,
Finally, as a general formatting request - some blank space between the end of the previous example and the header for the next field description would make the field descriptions much easier to read.
Hmm, I thought we were following stock ReST formats: perhaps the CSS should be adjusted to give a larger leading space to headings?
I've changed the layout yesterday, so its easier to read. Regards Tarek -- Tarek Ziadé | http://ziade.org
On Wed, Dec 23, 2009 at 11:18 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote: [..]
if a "1.2" field is found and no "1.1" field is found: metadata 1.2 is used if a "1.1" field is found and no "1.2" field is found: metadata 1.1 is used + a warning is displayed if a "1.1" field is found and a "1.2" field is found: a warning is displayed and 1.2 is used, 1.1 fields are ignored if no 1.1 field or 1.2 fields are found: metadata 1.2 is used
That would be internal to Distutils btw. tools should consume PKG-INFO using the DistributionMetadata reader, looking for the various attributes. "requires", etc. would be kept, most of the time set to "None", then removed at the next Python version.
The deprecation of the existing Requires/Provides/Obsoletes fields should be more prominent - tucked away below the examples, I missed these notices on the first read through (I only noticed that they actually had been formally deprecated when I got to the summary of differences at the end). I suggest placing the deprecation notice immediately after the relevant field headers.
I would go beyond deprecation, and propose to remove them altogether. In the metadata format, there is no point in deprecating something. If you have a valid use for these fields, use version 1.1.
There also needs to be an explanation in the PEP as to whether or not it is legal to use both Requires and Requires-Dist (etc) in the same PKG-INFO file. (i.e. what is the use case for allowing the old fields to be used in a metadata v1.2 PKG-INFO file? Should PEP 345 aware packaging tools just ignore the old fields, while v1.1 tools ignore the new ones? Or should new tools attempt to handle both?)
I think that depends much on the tool. Distutils will just write it into the metadata. PyPI will just store it in the database (and create new columns for the new fields), and render them to the user. The only issue would be with tools that actually do resolve dependencies. I believe that, for the old fields, no such tools actually exist. I may be wrong, in which case authors of such tools should speak up when the PEP proposes removal (or propose re-introduction in v1.3 of the format). Regards, Martin
2009/12/23 "Martin v. Löwis" <martin@v.loewis.de>:
The deprecation of the existing Requires/Provides/Obsoletes fields should be more prominent - tucked away below the examples, I missed these notices on the first read through (I only noticed that they actually had been formally deprecated when I got to the summary of differences at the end). I suggest placing the deprecation notice immediately after the relevant field headers.
I would go beyond deprecation, and propose to remove them altogether.
In the metadata format, there is no point in deprecating something. If you have a valid use for these fields, use version 1.1.
I think we want something stronger than that since they were not really used by the community and removed and replaced by something better. Using them should raise a warning so developers abandon them, so it would be "don't use 1.1 anymore" PEP 314 (PEP 345 predecessor) was implemented in a very particular manner: If you do use options like 'requires' in Distutils' setup.py, your package ends up with a PKG-INFO Metadata v1.1. Otherwise it stays v1.0. In other words, v1.0 was not really superseded by v1.1. The latter was just an alternative version and the current Distutils can produce both depending on the options you use in your setup.py. Once 1.2 is defined, we could deprecate the options that are corresponding to 1.1 at Distutils' level and make Distutils only produces metadata v1.2 PKG-INFO files (even if the options used by the developer could be written in a valid 1.0 format). This will be clearer I think. So, I am +1 for removing deprecated fields from PEP 345 and work on the deprecation issues at the code level in Distutils. Meaning Distutils' DistributionMetadata class will provide a way to read 1.0/1.1/1.2 but will only write 1.2 starting at 2.7/3.2, If a deprecated option is used, Distutils will produce a 1.1 with a warning. If a deprecated option is used together with a new option, like Require and Require-Dist, it will raise an error. Regards, Tarek
I think we want something stronger than that since they were not really used by the community and removed and replaced by something better. Using them should raise a warning so developers abandon them, so it would be "don't use 1.1 anymore"
I think you are mixing the distutils implementation (and parameters to the setup function) with PEP 345. This PEP *only* describes a data format. As such, it is not capable of raising exceptions. Whether you deprecate parameters to the setup function is an entirely different issue. Alternatives are removing them entirely, ignoring them, deprecating them, and conditionally accepting them (on the condition that they don't get mixed with parameters that are meant for 1.2 of the metadata).
PEP 314 (PEP 345 predecessor) was implemented in a very particular manner:
PEP 314 was implemented multiple times - not only in distutils, but also in PyPI (for example).
If you do use options like 'requires' in Distutils' setup.py, your package ends up with a PKG-INFO Metadata v1.1. Otherwise it stays v1.0.
Please do keep distutils out of PEP 345. The remaining occurrences (such as what the "interpret_marker" function does) should be removed.
In other words, v1.0 was not really superseded by v1.1. The latter was just an alternative version and the current Distutils can produce both depending on the options you use in your setup.py.
That is all well, and should probably be extended into the implementation of PEP 345 in distutils. However, what specifically distutils does is really not the subject here.
Once 1.2 is defined, we could deprecate the options that are corresponding to 1.1 at Distutils' level and make Distutils only produces metadata v1.2 PKG-INFO files (even if the options used by the developer could be written in a valid 1.0 format).
This will be clearer I think.
It would be also incompatible with existing consumers that expect a Python package to have an earlier version of the metadata. Dropping 1.0 may be fine though - but again, this is out of scope here. Regards, Martin
2009/12/23 "Martin v. Löwis" <martin@v.loewis.de>:
I think we want something stronger than that since they were not really used by the community and removed and replaced by something better. Using them should raise a warning so developers abandon them, so it would be "don't use 1.1 anymore"
I think you are mixing the distutils implementation (and parameters to the setup function) with PEP 345. This PEP *only* describes a data format. As such, it is not capable of raising exceptions.
I am just describing the needs and the end user PoV with the reference implementation that happens to be used by *all* tools out there. So that will happen in the code of course, but we need the PEP to state clearly wether metadata 1.0 and 1.1 should be dropped by implementations or not.
PEP 314 (PEP 345 predecessor) was implemented in a very particular manner:
PEP 314 was implemented multiple times - not only in distutils, but also in PyPI (for example).
PyPI doesn't produce PKG-INFO files AFAIK, it just consumes them, no ? I am referring to the implementation in Distutils that produces 1.0 *or* 1.1 PKG-INFO files.
If you do use options like 'requires' in Distutils' setup.py, your package ends up with a PKG-INFO Metadata v1.1. Otherwise it stays v1.0.
Please do keep distutils out of PEP 345. The remaining occurrences (such as what the "interpret_marker" function does) should be removed.
That's the reference implementation of a PEP 345 reader/writer that happens to be in the stdlin. For what reason should we remove it from the PEP ? [..]
Once 1.2 is defined, we could deprecate the options that are corresponding to 1.1 at Distutils' level and make Distutils only produces metadata v1.2 PKG-INFO files (even if the options used by the developer could be written in a valid 1.0 format).
This will be clearer I think.
It would be also incompatible with existing consumers that expect a Python package to have an earlier version of the metadata. Dropping 1.0 may be fine though - but again, this is out of scope here.
I don't understand why you are saying this is out of scope. Shouldn't we state clearly in the PEP that 1.0 and 1.1 should not be used in the future ? Regards Tarek -- Tarek Ziadé | http://ziade.org
So that will happen in the code of course, but we need the PEP to state clearly wether metadata 1.0 and 1.1 should be dropped by implementations or not.
Ok. We should recommend that implementations support these versions indefinitely. I see no point in dropping them. But then, this is really up to the implementations.
PEP 314 (PEP 345 predecessor) was implemented in a very particular manner: PEP 314 was implemented multiple times - not only in distutils, but also in PyPI (for example).
PyPI doesn't produce PKG-INFO files AFAIK, it just consumes them, no ?
Correct - but that's also an implementation of the PEP.
I am referring to the implementation in Distutils that produces 1.0 *or* 1.1 PKG-INFO files.
But it works both ways. Applications that consume then need to decide what versions they want to consume.
Please do keep distutils out of PEP 345. The remaining occurrences (such as what the "interpret_marker" function does) should be removed.
That's the reference implementation of a PEP 345 reader/writer that happens to be in the stdlin. For what reason should we remove it from the PEP ?
Because there shouldn't be a reference implementation. If we have both a spec and an a reference implementation, then we need to define what happens in case they conflict. If the reference implementation is right, implementers of the PEP would *also* need to study the reference implementation to find out what conforming behaviour is. This is bad; the PEP should be the only definition of the metadata format.
This will be clearer I think. It would be also incompatible with existing consumers that expect a Python package to have an earlier version of the metadata. Dropping 1.0 may be fine though - but again, this is out of scope here.
I don't understand why you are saying this is out of scope. Shouldn't we state clearly in the PEP that 1.0 and 1.1 should not be used in the future ?
In terms of conformance, what would that mean? If I implement 1.0 (in addition to also implementing 1.2), would I then be non-conforming (because the PEP says I should not support 1.0)? For PyPI, that would be fairly bad, as it will need to support earlier versions for many years to come (at a minimum, 10 years). Regards, Martin
Martin, As an application developer, I really stand with Tarek here. On Wed, 23 Dec 2009 20:07:30 +0100, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
2009/12/23 "Martin v. Löwis" <martin@v.loewis.de>:
I think we want something stronger than that since they were not really used by the community and removed and replaced by something better. Using them should raise a warning so developers abandon them, so it would be "don't use 1.1 anymore"
Yes. But that is a software warning message to be implemented within the installation software. The important thing is what is in the metadata.
I am just describing the needs and the end user PoV with the reference implementation that happens to be used by *all* tools out there.
That's good. That's what we need right now.
So that will happen in the code of course, but we need the PEP to state clearly wether metadata 1.0 and 1.1 should be dropped by implementations or not.
+1
It would be also incompatible with existing consumers that expect a Python package to have an earlier version of the metadata. Dropping 1.0 may be fine though - but again, this is out of scope here.
That's a software implementation issue. Not a metadata issue.
I don't understand why you are saying this is out of scope. Shouldn't we state clearly in the PEP that 1.0 and 1.1 should not be used in the future
I agree with you Tarek. Whilst we can suggest that the implementation be done in certain ways. The PEP in it's current form seems good enough an I am hoping it will go through soon. Three more years of deliberation and niggling on this PEP will have more of an adverse affect than a positive effect. It was started in 2005 and that seems like a long time to hold things up. There's always time for a 1.3 version in two years time if there is an unstoppable problem here - but I can't see any. As an application developer, I have to side with Tarek. Lets get this finalised. Thank you David
David Lyon writes:
I am just describing the needs and the end user PoV with the reference implementation that happens to be used by *all* tools out there.
That's good. That's what we need right now.
Martin's point is that the PEP process doesn't *have* "reference" implementations. It has *sample* implementations. It may be useful to refer to a sample implementation as an example, but the PEP must *define* the behaviors without such references, and compare the behavior of the sample to the defined behavior. And references to internal details like function names is inappropriate in most cases; I assume that is Martin's point here.
So that will happen in the code of course, but we need the PEP to state clearly wether metadata 1.0 and 1.1 should be dropped by implementations or not.
+1
You can state what you want. What implementations do is another matter. An implementation with lots of state like PyPI is not likely to change quickly. As a matter of user relations (including but not limited to developers like you), Python doesn't want to deprecate practices that are expensive to change too soon. (That's not my opinion about what is appropriate, that is my assessment of the historical policy of Python, which I don't think will change.)
On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
Martin's point is that the PEP process doesn't *have* "reference" implementations. It has *sample* implementations. It may be useful to refer to a sample implementation as an example..
Fair enough. But otoh, asking for sample implementations on this type of project can skew the PEP towards a particular implementation or product. A definition for metadata should be something quite abstract and self contained. So imo I am happier where it is currently.
What implementations do is another matter.
Right. We all agree on that.
An implementation with lots of state like PyPI is not likely to change quickly. As a matter of user relations (including but not limited to developers like you), Python doesn't want to deprecate practices that are expensive to change too soon. (That's not my opinion about what is appropriate, that is my assessment of the historical policy of Python, which I don't think will change.)
Well I would need more convincing that it is better to do one PEP every 4-5 years as a user relations exercise than one PEP every year or two years. Whilst I agree that the core language is really great and the rate of progress can happily slow. It would be nice to see the rate of progress of other areas, such as the metadata side, increase a little. That wouldn't break policy David
As an application developer, I really stand with Tarek here.
Not sure what specific point of Tarek you are supporting, though.
I think we want something stronger than that since they were not really used by the community and removed and replaced by something better. Using them should raise a warning so developers abandon them, so it would be "don't use 1.1 anymore"
Yes. But that is a software warning message to be implemented within the installation software. The important thing is what is in the metadata.
That's my point, not Tarek's, though (the text you quote and that you seem to object to is from Tarek).
I am just describing the needs and the end user PoV with the reference implementation that happens to be used by *all* tools out there.
That's good. That's what we need right now.
Why then bother with describing the data format, when you *really* want people to use the API? Shouldn't you then define the API instead, and leave the format as an implementation detail? I'm fine with having a sample implementation that tools *may* use, but it should be possible to implement the PEP without the sample implementation (and indeed, PyPI may not use that sample implementation, as it has already implemented most of the PEP, to support earlier versions).
So that will happen in the code of course, but we need the PEP to state clearly wether metadata 1.0 and 1.1 should be dropped by implementations or not.
+1
It would be also incompatible with existing consumers that expect a Python package to have an earlier version of the metadata. Dropping 1.0 may be fine though - but again, this is out of scope here.
That's a software implementation issue. Not a metadata issue.
Above you say that the PEP should specify whether to keep or drop 1.0 and 1.1, and now you say that whether dropping 1.0 is not a metadata issue (and, presumably, out of scope of the PEP)??? Regards, Martin
David Lyon wrote:
On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
Martin's point is that the PEP process doesn't *have* "reference" implementations. It has *sample* implementations. It may be useful to refer to a sample implementation as an example..
Fair enough. But otoh, asking for sample implementations on this type of project can skew the PEP towards a particular implementation or product.
Nobody is "asking" for sample implementations. Instead, I'm asking that what Tarek calls a "reference implementation" should be called a "sample implementation" instead. I'm asking for that precisely to avoid a skew towards a particular implementation. Regards, Martin
2009/12/23 "Martin v. Löwis" <martin@v.loewis.de>:
So that will happen in the code of course, but we need the PEP to state clearly wether metadata 1.0 and 1.1 should be dropped by implementations or not.
Ok. We should recommend that implementations support these versions indefinitely. I see no point in dropping them.
But then, this is really up to the implementations.
OK, that's fine with me. So I'll remove references to deprecated fields in PEP 345, which will just describes 1.2, and I will also remove the fact that it was marked as the replacer of PEP 314 in the header. [..]
PyPI doesn't produce PKG-INFO files AFAIK, it just consumes them, no ?
Correct - but that's also an implementation of the PEP.
I am referring to the implementation in Distutils that produces 1.0 *or* 1.1 PKG-INFO files.
But it works both ways. Applications that consume then need to decide what versions they want to consume.
They know it because it is marked in the file in the first line. e.g. a reader has to be able to read all versions. IOW they are not the ones that decide what metadata version a distribution contains.
Please do keep distutils out of PEP 345. The remaining occurrences (such as what the "interpret_marker" function does) should be removed.
That's the reference implementation of a PEP 345 reader/writer that happens to be in the stdlin. For what reason should we remove it from the PEP ?
Because there shouldn't be a reference implementation. If we have both a spec and an a reference implementation, then we need to define what happens in case they conflict. If the reference implementation is right, implementers of the PEP would *also* need to study the reference implementation to find out what conforming behaviour is.
This is bad; the PEP should be the only definition of the metadata format.
Ok, I'll remove that part. Regards Tarek -- Tarek Ziadé | http://ziade.org
On Thu, Dec 24, 2009 at 10:26 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
David Lyon wrote:
On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
Martin's point is that the PEP process doesn't *have* "reference" implementations. It has *sample* implementations. It may be useful to refer to a sample implementation as an example..
Fair enough. But otoh, asking for sample implementations on this type of project can skew the PEP towards a particular implementation or product.
Nobody is "asking" for sample implementations. Instead, I'm asking that what Tarek calls a "reference implementation" should be called a "sample implementation" instead. I'm asking for that precisely to avoid a skew towards a particular implementation.
I'll remove it and push it in Distutils documentation, then might just provide a link in the PEP References. Tarek
Martin v. Löwis wrote:
I'll remove it and push it in Distutils documentation, then might just provide a link in the PEP References.
That sounds fine to me.
That would address my questions as well - someone looking for a guide on how they should deal with different versions of the metadata on the production and consumption side can look at how distutils deals with it, leaving the PEP as a pure spec for the metadata format without distutils API details mixed in. (where it makes sense in explaining the use cases for the different fields, I'm fine with referencing distutils API details though) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Martin v. Löwis wrote:
I'll remove it and push it in Distutils documentation, then might just provide a link in the PEP References.
That sounds fine to me.
That would address my questions as well - someone looking for a guide on how they should deal with different versions of the metadata on the production and consumption side can look at how distutils deals with it, leaving the PEP as a pure spec for the metadata format without distutils API details mixed in.
(where it makes sense in explaining the use cases for the different fields, I'm fine with referencing distutils API details though)
I've updated the PEP accordingly, and also made some changes after the discussions we had with Martin on Distutils-SIG on how versions are defined. FYI we have introduced a range operator, so one may define a range of versions. This is useful for instance to write: Requires-Python: ~=2.5 Which means: requires any version of Python 2.5.x. This operator is the default operator, meaning that you can also write: Requires-Python: 2.5 Regards Tarek
On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Martin v. Löwis wrote: FYI we have introduced a range operator, so one may define a range of versions. This is useful for instance to write:
Requires-Python: ~=2.5
Which means: requires any version of Python 2.5.x. This operator is the default operator, meaning that you can also write:
Requires-Python: 2.5
I don't like the ~ at all sorry. The ~ operator is thoroughly confusing. No application developer will quickly figure out what a tilde means. Maybe it means 'roughly', but it requires too much thought and is ambiguous. 2.5 is not roughly 2.5.2. It is the same exactly. Before we had : Requires-Python: 2.5, 2.6 That made much more sense. It was simple and unambiguous, and is relevant to typical packaging scenarios. I hope we can go back to the original proposal. :-) David
On Mon, Dec 28, 2009 at 1:15 AM, <david.lyon@preisshare.net> wrote:
On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Martin v. Löwis wrote: FYI we have introduced a range operator, so one may define a range of versions. This is useful for instance to write:
Requires-Python: ~=2.5
Which means: requires any version of Python 2.5.x. This operator is the default operator, meaning that you can also write:
Requires-Python: 2.5
I don't like the ~ at all sorry. The ~ operator is thoroughly confusing.
No application developer will quickly figure out what a tilde means. Maybe it means 'roughly', but it requires too much thought and is ambiguous. 2.5 is not roughly 2.5.2. It is the same exactly.
As discussed in Distutils-SIG, 2.5 is not strictly equal to 2.5.2. That's exactly why we introduced the range operator. So one may make a clear distinction between "2.5.x" and "2.5". Developers will be able to omit the ~= operator, so they can describe a MAJOR or MAJOR.MINOR version and have the whole range included.
Before we had : Requires-Python: 2.5, 2.6
That made much more sense. It was simple and unambiguous, and is relevant to typical packaging scenarios.
This was ambiguous because it was unclear, as MvL stated, if "2.5" was just "2.5.0" or included versions like "2.5.1" or "2.5.2". The "==" operator is now a strict equal operator. In the current proposal, "Requires-Python: 2.5, 2.6" is equivalent to "Requires-Python: ~=2.5, ~=2.6", which means "Requires Python 2.5.x or Python 2.6.x". So I guess the meaning you were putting behind "Requires-Python: 2.5, 2.6" remains unchanged.
I hope we can go back to the original proposal.
This new operator removes the ambiguity the original proposal had, without making it more complex for common use cases. So if you dislike it, you will need to propose something else that also fixes the ambiguity we had. Regards, Tarek
On 12/27/2009 4:15 PM, david.lyon@preisshare.net wrote:
On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan<ncoghlan@gmail.com> wrote:
Martin v. Löwis wrote: FYI we have introduced a range operator, so one may define a range of versions. This is useful for instance to write:
Requires-Python: ~=2.5
Which means: requires any version of Python 2.5.x. This operator is the default operator, meaning that you can also write:
Requires-Python: 2.5 I don't like the ~ at all sorry. The ~ operator is thoroughly confusing.
No application developer will quickly figure out what a tilde means. Maybe it means 'roughly', but it requires too much thought and is ambiguous. 2.5 is not roughly 2.5.2. It is the same exactly.
Tarek, I am a bit confused at the current proposal combined with the newly introduced range operator. Would "Requires-Python: <=2.5" include 2.5.4 or not? Also, "Requires-Python: 3" would include all 3.X versions, correct? -srid
Tarek Ziadé <ziade.tarek <at> gmail.com> writes:
This was ambiguous because it was unclear, as MvL stated, if "2.5" was just "2.5.0" or included versions like "2.5.1" or "2.5.2".
How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5 itself? (ditto for "2.5.N" matching only 2.5.N for N >= 1) This "~=" operator looks murkier than it needs to be IMO. Regards Antoine.
On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar <sridharr@activestate.com> wrote: [..]
Tarek,
I am a bit confused at the current proposal combined with the newly introduced range operator.
Would "Requires-Python: <=2.5" include 2.5.4 or not?
<=2.5 means any version that is inferior or equal to 2.5.0 so 2.5.4 doesn't match
Also, "Requires-Python: 3" would include all 3.X versions, correct?
Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= 3" which is equivalent to "Requires-Python: 3.x.x"
-srid
-- Tarek Ziadé | http://ziade.org
No application developer will quickly figure out what a tilde means. Maybe it means 'roughly', but it requires too much thought and is ambiguous. 2.5 is not roughly 2.5.2. It is the same exactly.
Before we had : Requires-Python: 2.5, 2.6
That made much more sense. It was simple and unambiguous, and is relevant to typical packaging scenarios.
Unfortunately, it is fairly ambiguous, and makes no sense. It means "requires Python 2.5 *AND* requires Python 2.6", which is a requirement that no single version can meet. Regards, Martin
On Mon, Dec 28, 2009 at 1:48 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Tarek Ziadé <ziade.tarek <at> gmail.com> writes:
This was ambiguous because it was unclear, as MvL stated, if "2.5" was just "2.5.0" or included versions like "2.5.1" or "2.5.2".
How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5 itself? (ditto for "2.5.N" matching only 2.5.N for N >= 1)
This "~=" operator looks murkier than it needs to be IMO.
An implicit range operator is simpler indeed, and achieves the same goal. Meaning that "<=2.5" for example, will be translated to "<=2.5.x" as well. Regards, Tarek
Tarek Ziadé <ziade.tarek@gmail.com> writes:
FYI we have introduced a range operator, so one may define a range of versions. This is useful for instance to write:
Requires-Python: ~=2.5
Which means: requires any version of Python 2.5.x.
-1 on that syntax. It's an extra operator, with a non-obvious meaning; the meaning should be as clear as feasible even to those who have not read the specification. The existing operators ‘>’, ‘>=’, ‘<’ ‘<=’ are standard and more obvious. That is, the existing operators: Requires-Python: >=2.5, <2.6 explicitly specify the range in your example. -- \ “Value your freedom or you will lose it, teaches history. | `\ “Don't bother us with politics,” respond those who don't want | _o__) to learn.” —Richard Stallman, 2002 | Ben Finney
Tarek Ziadé wrote:
On Mon, Dec 28, 2009 at 1:48 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Tarek Ziadé <ziade.tarek <at> gmail.com> writes:
This was ambiguous because it was unclear, as MvL stated, if "2.5" was just "2.5.0" or included versions like "2.5.1" or "2.5.2". How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5 itself? (ditto for "2.5.N" matching only 2.5.N for N >= 1)
This "~=" operator looks murkier than it needs to be IMO.
An implicit range operator is simpler indeed, and achieves the same goal.
Meaning that "<=2.5" for example, will be translated to "<=2.5.x" as well.
So that "2.5.4<=2.5", "2.5<=2.5.2", but not "2.5.4<=2.5.2" (i.e. A<=B, B<=C, but not A<=C)? I find that strange. Regards, Martin
Tarek Ziadé <ziade.tarek@gmail.com> writes:
On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar <sridharr@activestate.com> wrote:
Also, "Requires-Python: 3" would include all 3.X versions, correct?
Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= 3" which is equivalent to "Requires-Python: 3.x.x"
This is totally counter to conventional comparisons, and is an excellent example of why the equivalence of ‘3’ to ‘>=3, <4’ is a bad idea. Instead, the default should be ‘==’. That is, ‘Requires-Python: 3’ should be equivalent to ‘Requires-Python: ==3’; and only “3” or “3.0” or “3.0.0” etc. will match. I maintain that is what most people will expect on seeing that syntax. If a less strict range is desired, the existing comparison operators ‘>’, ‘>=’, ‘<’, ‘<=’ are sufficient, more obvious, and more explicit. In other words, to get the meaning you desire above, the existing operators can be used: ‘Requires-Python: >=3, <4’. -- \ “Not using Microsoft products is like being a non-smoker 40 or | `\ 50 years ago: You can choose not to smoke, yourself, but it's | _o__) hard to avoid second-hand smoke.” —Michael Tiemann | Ben Finney
Tarek Ziadé wrote:
On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar <sridharr@activestate.com> wrote: [..]
Tarek,
I am a bit confused at the current proposal combined with the newly introduced range operator.
Would "Requires-Python: <=2.5" include 2.5.4 or not?
<=2.5 means any version that is inferior or equal to 2.5.0 so 2.5.4 doesn't match
Also, "Requires-Python: 3" would include all 3.X versions, correct?
Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= 3" which is equivalent to "Requires-Python: 3.x.x"
To me it's non-intuitive that "<=2.5" means <=2.5.0 but "2.5" means 2.5.x; it's not consistent, explicit is better than implicit, etc. I'd prefer it if omission means "don't care", so "2" means 2.x.y and "2.5" means 2.5.x.
Ben Finney wrote:
Tarek Ziadé <ziade.tarek@gmail.com> writes:
On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar <sridharr@activestate.com> wrote:
Also, "Requires-Python: 3" would include all 3.X versions, correct? Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= 3" which is equivalent to "Requires-Python: 3.x.x"
This is totally counter to conventional comparisons, and is an excellent example of why the equivalence of ‘3’ to ‘>=3, <4’ is a bad idea.
Instead, the default should be ‘==’. That is, ‘Requires-Python: 3’ should be equivalent to ‘Requires-Python: ==3’; and only “3” or “3.0” or “3.0.0” etc. will match. I maintain that is what most people will expect on seeing that syntax.
If a less strict range is desired, the existing comparison operators ‘>’, ‘>=’, ‘<’, ‘<=’ are sufficient, more obvious, and more explicit. In other words, to get the meaning you desire above, the existing operators can be used: ‘Requires-Python: >=3, <4’.
Perhaps there should be a new range operator: Requires-Python: 3 ~ 4 Half-open, of course.
2009-12-28 02:17:22 Ben Finney napisał(a):
Tarek Ziadé <ziade.tarek@gmail.com> writes:
On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar <sridharr@activestate.com> wrote:
Also, "Requires-Python: 3" would include all 3.X versions, correct?
Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= 3" which is equivalent to "Requires-Python: 3.x.x"
This is totally counter to conventional comparisons, and is an excellent example of why the equivalence of ‘3’ to ‘>=3, <4’ is a bad idea.
Instead, the default should be ‘==’. That is, ‘Requires-Python: 3’ should be equivalent to ‘Requires-Python: ==3’; and only “3” or “3.0” or “3.0.0” etc. will match. I maintain that is what most people will expect on seeing that syntax.
If a less strict range is desired, the existing comparison operators ‘>’, ‘>=’, ‘<’, ‘<=’ are sufficient, more obvious, and more explicit. In other words, to get the meaning you desire above, the existing operators can be used: ‘Requires-Python: >=3, <4’.
IMHO 'Requires-Python: 3*' (or '3.*') would be better than 'Requires-Python: >=3, <4'. -- Arfrever Frehtes Taifersar Arahesis
On Sun, Dec 27, 2009 at 8:28 PM, Arfrever Frehtes Taifersar Arahesis <arfrever.fta@gmail.com> wrote:
'Requires-Python: 3*' (or '3.*') would be better than 'Requires-Python: >=3, <4'.
Maybe. MRAB wrote:
Requires-Python: 3 ~ 4
Ugh. -1 -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On 12/27/2009 5:21 PM, MRAB wrote:
Tarek Ziadé wrote:
On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar <sridharr@activestate.com> wrote: [..]
Tarek,
I am a bit confused at the current proposal combined with the newly introduced range operator.
Would "Requires-Python: <=2.5" include 2.5.4 or not?
<=2.5 means any version that is inferior or equal to 2.5.0 so 2.5.4 doesn't match
Also, "Requires-Python: 3" would include all 3.X versions, correct?
Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= 3" which is equivalent to "Requires-Python: 3.x.x"
To me it's non-intuitive that "<=2.5" means <=2.5.0 but "2.5" means 2.5.x; it's not consistent, explicit is better than implicit, etc.
Yes. When we talk about Python-2.5 (as in, for instance, "this script requires Python 2.5 to run"), we are referring to 2.5.x, and not just 2.5.0.
I'd prefer it if omission means "don't care", so "2" means 2.x.y and "2.5" means 2.5.x.
+1. On 12/27/2009 4:37 PM, Tarek Ziadé wrote:
As discussed in Distutils-SIG, 2.5 is not strictly equal to 2.5.2. That's exactly why we introduced the range operator. So one may make a clear distinction between "2.5.x" and "2.5".
Perhaps if "2.5" was instead considered to be a *range* of possible versions (2.5.0, ... 2.5.4), then this ambiguity wouldn't have arisen in first place? Technically (Include/patchlevel.h), it is "2.5.0", not "2.5". -srid
Arfrever Frehtes Taifersar Arahesis wrote:
2009-12-28 02:17:22 Ben Finney napisał(a):
Tarek Ziadé <ziade.tarek@gmail.com> writes:
On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar <sridharr@activestate.com> wrote:
Also, "Requires-Python: 3" would include all 3.X versions, correct? Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= 3" which is equivalent to "Requires-Python: 3.x.x" This is totally counter to conventional comparisons, and is an excellent example of why the equivalence of ‘3’ to ‘>=3, <4’ is a bad idea.
Instead, the default should be ‘==’. That is, ‘Requires-Python: 3’ should be equivalent to ‘Requires-Python: ==3’; and only “3” or “3.0” or “3.0.0” etc. will match. I maintain that is what most people will expect on seeing that syntax.
If a less strict range is desired, the existing comparison operators ‘>’, ‘>=’, ‘<’, ‘<=’ are sufficient, more obvious, and more explicit. In other words, to get the meaning you desire above, the existing operators can be used: ‘Requires-Python: >=3, <4’.
IMHO 'Requires-Python: 3*' (or '3.*') would be better than 'Requires-Python: >=3, <4'.
'3.*' would be the better of the two.
Martin v. Löwis wrote:
No application developer will quickly figure out what a tilde means. Maybe it means 'roughly', but it requires too much thought and is ambiguous. 2.5 is not roughly 2.5.2. It is the same exactly.
Before we had : Requires-Python: 2.5, 2.6
That made much more sense. It was simple and unambiguous, and is relevant to typical packaging scenarios.
Unfortunately, it is fairly ambiguous, and makes no sense. It means "requires Python 2.5 *AND* requires Python 2.6", which is a requirement that no single version can meet.
Does that mean we should add "or"? Requires-Python: 2.5 or 2.6 Should we also use "and" instead of ","? Requires-Python: >= 2.5 and < 2.6
On Dec 27, 2009, at 8:02 PM, Tarek Ziadé wrote:
On Mon, Dec 28, 2009 at 1:48 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Tarek Ziadé <ziade.tarek <at> gmail.com> writes:
This was ambiguous because it was unclear, as MvL stated, if "2.5" was just "2.5.0" or included versions like "2.5.1" or "2.5.2".
How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5 itself? (ditto for "2.5.N" matching only 2.5.N for N >= 1)
This "~=" operator looks murkier than it needs to be IMO.
An implicit range operator is simpler indeed, and achieves the same goal.
Meaning that "<=2.5" for example, will be translated to "<=2.5.x" as well.
It seems to me that all this version range talk relates pretty directly to PEP 386. The Python version numbers themselves are the simplest type of "Normalized Version"s, and since comparisons of "NormalizedVersion"s are defined in PEP 386, and that's really all we're talking about here, shouldn't this really just follow and reference that document? Sure we might like some sugar to make expressing ranges simpler, but shouldn't the explicit meanings of any rules be stated in terms of Normalized Version comparisons? S
Ben Finney writes:
Instead, the default should be `=='. That is, `Requires-Python: 3' should be equivalent to `Requires-Python: ==3'; and only "3" or "3.0" or "3.0.0" etc. will match. I maintain that is what most people will expect on seeing that syntax.
I really don't think your assessment that a majority agrees with you is warranted. The demand for backward compatibility is so strong that (wearing my maintainer hat, in other projects) I actually assume that in compatibility claims a bare version number like 3 means >= 3.0.0 to my listeners, unless explicitly qualified. Therefore, I think there should be no default. "Explicit is better than implicit." And IMO the choice of "~=" or "=~" for the range match should be avoided, since that looks like the regexp search operator in Perl, and there "~= 3" would match "3", "3.0.4", and "2.3.5". The next obvious interpretation is "fuzzy match", but that doesn't have an obvious, more specific meaning. The usual comparson operators do have pretty obvious interpretations, and are not hard to use.
No application developer will quickly figure out what a tilde means. Maybe it means 'roughly', but it requires too much thought and is ambiguous. 2.5 is not roughly 2.5.2. It is the same exactly.
Before we had : Requires-Python: 2.5, 2.6
That made much more sense. It was simple and unambiguous, and is relevant to typical packaging scenarios.
Unfortunately, it is fairly ambiguous, and makes no sense. It means "requires Python 2.5 *AND* requires Python 2.6", which is a requirement that no single version can meet.
No, it means a library requires either python 2.5 *OR* python 2.6 to be installed properly. If not, the implication is that the user will be prompted to install anyway. David
Instead, the default should be â==â. That is, âRequires-Python: 3â should be equivalent to âRequires-Python: ==3â; and only â3â or â3.0â or â3.0.0â etc. will match. I maintain that is what most people will expect on seeing that syntax.
If a less strict range is desired, the existing comparison operators â>â, â>=â, â<â, â<=â are sufficient, more obvious, and more explicit. In other words, to get the meaning you desire above, the existing operators can be used: âRequires-Python: >=3, <4â.
Yes, so that: Requires-Python: 1,2,3 means python versions 1,2 or 3. Requires-Python: 3 means requires python 3 only. Any version of 3 Whereas: Requires-Python: 3.0, 3.1 means only 3.0 and 3.1 Requires-Python: 2.3, 2.4, 2.5, 2.6 That means, those particular versions. A user can still try to install on other versions. But they would get a warning and would do so at their own risk. There's no need for extra operator characters as far as I can see. The comma method proposed originally seemed to do everything. David
On 12/27/2009 7:48 PM, Antoine Pitrou wrote:
Tarek Ziadé<ziade.tarek<at> gmail.com> writes:
This was ambiguous because it was unclear, as MvL stated, if "2.5" was just "2.5.0" or included versions like "2.5.1" or "2.5.2".
How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5 itself? (ditto for "2.5.N" matching only 2.5.N for N>= 1)
If the first x.y release were called x.y.0, (does not sys.version include 0?) then x.y would unambiguously mean the series.
This "~=" operator looks murkier than it needs to be IMO.
Agreed, though not likely to affect me too much. Terry Jan Reedy
Tarek Ziadé <ziade.tarek <at> gmail.com> writes: An implicit range operator is simpler indeed, and achieves the same goal.
Meaning that "<=2.5" for example, will be translated to "<=2.5.x" as well.
With respect, it's not a very common use case for a developer to say that package needs a python interpretor 'older' than 2.5. There comes a point where you can just not expect a python interpretor, say 1.3, to not work with your package. So they wouldn't say that. I don't think. Nor would they say it going forward. So ">=2.5" might be too bold a claim for them to make. As they might not have tested on the 'latest-and-greatest' interpretor. That would imply that they know it works on all 3 series interpretors. imho, all that they would know, is that they're using python (for example) 2.4 or 2.5 (pick a python version) and they know it works pretty well. It's then up to the user if they want to use it on any other version. That's why I don't think we need the '=' '>=' operator characters to represent typical use cases. If there's any use-case, that I have missed. Do let me know. David
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Terry Reedy wrote:
On 12/27/2009 7:48 PM, Antoine Pitrou wrote:
Tarek Ziadé<ziade.tarek<at> gmail.com> writes:
This was ambiguous because it was unclear, as MvL stated, if "2.5" was just "2.5.0" or included versions like "2.5.1" or "2.5.2". How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5 itself? (ditto for "2.5.N" matching only 2.5.N for N>= 1)
If the first x.y release were called x.y.0, (does not sys.version include 0?) then x.y would unambiguously mean the series.
This syntax is not just for the 'Requires-Python:' field, but also for the 'Requires-Dist:' and 'Obsoletes-Dist:' fields: not all third-party packages call the first release of a given series .0. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks4PzUACgkQ+gerLs4ltQ551gCgyVNvpJayTWGiCNbg4NKw4p/y uG8An1u90cHfKVaUqIAkUlZSI92g6PxL =7h2c -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziadé wrote:
On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar <sridharr@activestate.com> wrote: [..]
Tarek,
I am a bit confused at the current proposal combined with the newly introduced range operator.
Would "Requires-Python: <=2.5" include 2.5.4 or not?
<=2.5 means any version that is inferior or equal to 2.5.0 so 2.5.4 doesn't match
Also, "Requires-Python: 3" would include all 3.X versions, correct?
Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= 3" which is equivalent to "Requires-Python: 3.x.x"
Point of order: what is the point of sending the discussion off to the distutils SIG if we are just going to bikeshed it (again!) here. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks4QAwACgkQ+gerLs4ltQ5LJACfY9ijtkw/Bsyg2xXp93xNtbhy QAUAnRBZWSMk+izGDEjVkHVLpu418gfR =vM/V -----END PGP SIGNATURE-----
david.lyon@preisshare.net writes:
Before we had : Requires-Python: 2.5, 2.6
That made much more sense. It was simple and unambiguous, and is relevant to typical packaging scenarios.
Unfortunately, it is fairly ambiguous, and makes no sense. It means "requires Python 2.5 *AND* requires Python 2.6", which is a requirement that no single version can meet.
No, it means a library requires either python 2.5 *OR* python 2.6 to be installed properly.
If Martin and the SIG disagree on the interpretation (and I see Martin's point: in ">=2.5, <2.6" the comma is a conjunction, not a disjunction), that's too much ambiguity for me. -1
On Mon, Dec 28, 2009 at 05:37, Terry Reedy <tjreedy@udel.edu> wrote:
If the first x.y release were called x.y.0, (does not sys.version include 0?) then x.y would unambiguously mean the series.
Yeah, well, although sys.version includes the zero, nothing else does. The first releases are called 2.5, which is ambiguous. Both Python and Plone leaves out the zero in the version name. IMO that's a bug. But that's now how it is. However, there are two ways of writing versions that are completely unambiguous and which every programmer will immediately understand: 2.5.0 and 2.5.* Done. The comma is problematic. If you want to specify 2.5 or 2.6, it would be natural to write: Requires-Python: 2.5.*, 2.6.* Which clearly has the comma meaning "or". But it would also make sense to write: Requires-Python: >= 2.5.2, < 3.0.0 Where it is an "and". But trying to leave commas out leaves us with the slightly weird syntax of Requires-Python: >= 2.5.2 and < 3.0.0 or >= 3.1.* And then it's the question of in what order that should be interpreted. And what would Requires-Python: >= 3.1.* or >= 2.5.2 and < 3.0.0 mean? And would Requires-Python: >= 2.5.2 or >= 3.1.* and < 3.0.0 Be legal an mean anything? My conclusion: This is a place where the normal computer logic syntax makes so sense, it's either too restrictive, or too flexible. We need something custom, where we can specify pairs of two versions, min and max and have several pairs. Also, the min version can always be included and the max version excluded. You need to write things like:
= 2.5.2 and < 3.0.0. You never need to write <= 2.5.7, because you can always write < 2.5.8 instead.
Now, this "starting from and then up until but not including" is something that is quite common in Python. Namely when slicing. It works exactly like that. [3:9] means from 3 and up until but not including 9. Hence, a clear and unambiguous and extremely Pythonic way of specifying a version range is: [2.5.2:3.0.0]. No <= or commas anywhere. We can also specify a list of ranges by having semicolons between them. The grammar ends up something like this: versionrequirements ::= 'Requires-Python: ' specificationlist specificationlist ::= specification (; specification)* specification ::= version | "[" [version] ":" [version] "]" version ::= lc_number "." (lc_number | "*") "." [lc_number | "*"] With examples being: Requires-Python: [2.5.2:3.0.0]; [3.1.*:] Or on several rows: Requires-Python: [2.5.2:3.0.0]; [3.1.2:]; [3.2.*] Now, if <=>== etc is deemed necessary, we could use something like this: versionrequirements ::= 'Requires-Python: ' specificationlist specificationlist ::= specification (; specification)* specification ::= version | minimum | maximum | miniumum " " maximum minimum ::= ('>' | '>=') version maximum ::= ('<' | '<=') version version ::= lc_number "." (lc_number | "*") "." [lc_number | "*"] That would mean something like the following: Requires-Python: >= 2.5.2 < 3.0.0; >= 3.1* or more clearer if it's split up in lines: Requires-Python: >= 2.5.2 < 3.0.0; >= 3.1* The following would be illegal: Requires-Python: >= 2.5.2 > 3.0.0 Requires-Python: <= 2.5.2 < 3.0.0 Requires-Python: <= 2.5.2 < 3.0.0 > 3.1* No commas or ands or ors anywhere. But I like the first syntax better.
david.lyon@preisshare.net writes:
With respect, it's not a very common use case for a developer to say that package needs a python interpretor 'older' than 2.5.
Of course it is. I don't claim it is the majority of cases out there, but stable versions of many of the packages I use will specify an older python (Mailman and Zope both specify a range of Pythons, rarely including the most recent release, and Bazaar, although it tries to keep up with Python releases, tends to recommend being conservative, sticking to release (n-1) for the first few months into release n.) And in fact this case is often more the important one. Packages that depend on having a *recent* version of python will often crash quickly, before doing permanent damage, when an undefined syntax, function, or method is invoked, while packages that depend on a quirk in behavior of an older version will typically silently corrupt data.
imho, all that they would know, is that they're using python (for example) 2.4 or 2.5 (pick a python version) and they know it works pretty well.
If they want to specify a Python version that works, they may as well bundle it, and many do. But even in that case the user may want to know about the dependency. BTW, *all* of the Python applications I really care about make a point of specifying a range of versions they work with (or bundle a particular version). So in fact many developers do know what versions work or fail, and often why (and they sometimes even provide workarounds/patches for adventurers who want to use a Python outside of the recommended range).
It's then up to the user if they want to use it on any other version.
This is often an undesirable posture. From the user's point of view, the system version of Python may have passed various local tests and therefore be strongly preferred (for example, requiring far less time for approval from the security team). This is especially true for mail or web applications and other applications that must run in a very hostile environment. Many developers do want to provide this kind of information to such users. I think you should rethink your position on how valid your personal intuitions are for generalization. You are certainly representative of a certain important segment of developers, but I don't think you have a good sense of the very broad class of requirements that other developers are bringing to the table.
And in fact this case is often more the important one. Packages that depend on having a *recent* version of python will often crash quickly, before doing permanent damage, when an undefined syntax, function, or method is invoked, while packages that depend on a quirk in behavior of an older version will typically silently corrupt data.
How can they know that they depend on "a quirk in behaviour of an older version" if a newer version hasn't been released? This sounds bogus. Besides, not letting me install their app/library on a newer Python just because they are not /sure/ it will work is IMO an active nuisance. The user should be treated as an adult.
david.lyon@preisshare.net writes:
With respect, it's not a very common use case for a developer to say that package needs a python interpretor 'older' than 2.5.
Of course it is. I don't claim it is the majority of cases out there, but stable versions of many of the packages I use will specify an older python (Mailman and Zope both specify a range of Pythons, rarely including the most recent release, and Bazaar, although it tries to keep up with Python releases, tends to recommend being conservative, sticking to release (n-1) for the first few months into release n.)
And in fact this case is often more the important one. Packages that depend on having a *recent* version of python will often crash quickly, before doing permanent damage, when an undefined syntax, function, or method is invoked, while packages that depend on a quirk in behavior of an older version will typically silently corrupt data.
imho, all that they would know, is that they're using python (for example) 2.4 or 2.5 (pick a python version) and they know it works pretty well.
If they want to specify a Python version that works, they may as well bundle it, and many do. But even in that case the user may want to know about the dependency.
BTW, *all* of the Python applications I really care about make a point of specifying a range of versions they work with (or bundle a particular version). So in fact many developers do know what versions work or fail, and often why (and they sometimes even provide workarounds/patches for adventurers who want to use a Python outside of the recommended range).
It's then up to the user if they want to use it on any other version.
This is often an undesirable posture. From the user's point of view, the system version of Python may have passed various local tests and therefore be strongly preferred (for example, requiring far less time for approval from the security team). This is especially true for mail or web applications and other applications that must run in a very hostile environment. Many developers do want to provide this kind of information to such users.
I think you should rethink your position on how valid your personal intuitions are for generalization. You are certainly representative of a certain important segment of developers, but I don't think you have a good sense of the very broad class of requirements that other developers are bringing to the table.
Hi Stephen,
BTW, *all* of the Python applications I really care about make a point of specifying a range of versions they work with (or bundle a particular version).
Yes, well that was my point exactly. If opinion is against commas, then we can take them out. That would give us something like: Requires-python: 2.5 2.6 2.7 3 That would specify a bundle of versions. Processing that only requires the string split() function. If we were to adds Lens suggestion of the range indicator that would simplify things even more. Requires-python: 2.5:2.7 3 That would specify everything between 2.5 and 2.7 and then everything in the 3 series. This would make it very simple. David
On Mon, Dec 28, 2009 at 7:39 AM, Lennart Regebro <regebro@gmail.com> wrote:
On Mon, Dec 28, 2009 at 05:37, Terry Reedy <tjreedy@udel.edu> wrote:
If the first x.y release were called x.y.0, (does not sys.version include 0?) then x.y would unambiguously mean the series.
Yeah, well, although sys.version includes the zero, nothing else does. The first releases are called 2.5, which is ambiguous. Both Python and Plone leaves out the zero in the version name. IMO that's a bug. But that's now how it is.
Yes but in PEP 386 semantics, 2.5 will be equivalent to 2.5.0, so it doesn't matter if a software doesn't use the .0 Tarek -- Tarek Ziadé | http://ziade.org
On Mon, Dec 28, 2009 at 6:20 AM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tarek Ziadé wrote:
On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar <sridharr@activestate.com> wrote: [..]
Tarek,
I am a bit confused at the current proposal combined with the newly introduced range operator.
Would "Requires-Python: <=2.5" include 2.5.4 or not?
<=2.5 means any version that is inferior or equal to 2.5.0 so 2.5.4 doesn't match
Also, "Requires-Python: 3" would include all 3.X versions, correct?
Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= 3" which is equivalent to "Requires-Python: 3.x.x"
Point of order: what is the point of sending the discussion off to the distutils SIG if we are just going to bikeshed it (again!) here.
What happened is that Martin came late in the discussions in Distutils-SIG after I've forwarded the final mail in Catalog-SIG and after I did send it here (the mail where I said "Here's the mail I'll send to python-dev for PEP 345, if anyone sees a problem or something to add") I agree that the comma and syntax discussions are bikeshedding. Although I don't think the range discussion is bikeshedding, and so far we made some progress on clarifying how range versions are compared in that PEP through Martin's points and this thread. It's quite important IMHO to clarify it. So, if no one object, I propose to continue this thread about the way range should be compared, to see if we meet a consensus quite soon. If not, I guess we can go back to distutils-SIG and invite people over there, as we did for other topics. Regards, Tarek -- Tarek Ziadé | http://ziade.org
On Mon, Dec 28, 2009 at 6:16 AM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Terry Reedy wrote:
On 12/27/2009 7:48 PM, Antoine Pitrou wrote:
Tarek Ziadé<ziade.tarek<at> gmail.com> writes:
This was ambiguous because it was unclear, as MvL stated, if "2.5" was just "2.5.0" or included versions like "2.5.1" or "2.5.2". How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5 itself? (ditto for "2.5.N" matching only 2.5.N for N>= 1)
If the first x.y release were called x.y.0, (does not sys.version include 0?) then x.y would unambiguously mean the series.
This syntax is not just for the 'Requires-Python:' field, but also for the 'Requires-Dist:' and 'Obsoletes-Dist:' fields: not all third-party packages call the first release of a given series .0.
They do start with "2.5" *or* "2.5.0" for their first release of the 2.5 series. And both are equal for PEP 386. IOW "2.5 == 2.5.0", always. So it doesn't really matter if some projects don't use the terminal 0 here. Antoine's proposal still works. Tarek
On Mon, Dec 28, 2009 at 3:03 AM, MRAB <python@mrabarnett.plus.com> wrote:
Martin v. Löwis wrote:
No application developer will quickly figure out what a tilde means. Maybe it means 'roughly', but it requires too much thought and is ambiguous. 2.5 is not roughly 2.5.2. It is the same exactly.
Before we had : Requires-Python: 2.5, 2.6
That made much more sense. It was simple and unambiguous, and is relevant to typical packaging scenarios.
Unfortunately, it is fairly ambiguous, and makes no sense. It means "requires Python 2.5 *AND* requires Python 2.6", which is a requirement that no single version can meet.
Does that mean we should add "or"?
Requires-Python: 2.5 or 2.6
Should we also use "and" instead of ","?
Requires-Python: >= 2.5 and < 2.6
This was discussed aready in Ditsutils-SIG : *and* is enough to express everything, so for the sake of simplicity, the comma means *and* all the time, as Mentioned in http://www.python.org/dev/peps/pep-0345/#version-specifiers Regards Tarek
david.lyon@preisshare.net wrote:
No application developer will quickly figure out what a tilde means. Maybe it means 'roughly', but it requires too much thought and is ambiguous. 2.5 is not roughly 2.5.2. It is the same exactly.
Before we had : Requires-Python: 2.5, 2.6
That made much more sense. It was simple and unambiguous, and is relevant to typical packaging scenarios. Unfortunately, it is fairly ambiguous, and makes no sense. It means "requires Python 2.5 *AND* requires Python 2.6", which is a requirement that no single version can meet.
No, it means a library requires either python 2.5 *OR* python 2.6 to be installed properly.
Well, the PEP says that the comma means "and", see http://www.python.org/dev/peps/pep-0345/#version-specifiers If the comma would mean "or", then what would ">1.0, !=1.3.4, <2.0" mean? above 1.0 OR unequal to 1.3.4 OR below 2.0 That would mean that *any* version would match that spec, and then the spec would be meaningless. If that's not clear, ask whether 4.0 would match: yes, it would, because it's >1.0. What about 0.9: yes, it's <2.0. Regards, Martin
Tarek Ziadé <ziade.tarek@gmail.com> writes:
What happened is that Martin came late in the discussions in Distutils-SIG after I've forwarded the final mail in Catalog-SIG and after I did send it here (the mail where I said "Here's the mail I'll send to python-dev for PEP 345, if anyone sees a problem or something to add")
I was under the impression that previous art was being followed in the area of specifying dependencies. That previous art being the many existing dependency systems, which use obvious comparison operators (the ‘>’ ‘>=’ ‘<’ ‘<=’) and no range operators or implicit ranges.
So, if no one object, I propose to continue this thread about the way range should be compared, to see if we meet a consensus quite soon. If not, I guess we can go back to distutils-SIG and invite people over there, as we did for other topics.
Please, keep the operators simple and obvious, drawing on the existing conventions in other systems, so there's no need to have bike-shedding discussions over new syntax. -- \ “Science is a way of trying not to fool yourself. The first | `\ principle is that you must not fool yourself, and you are the | _o__) easiest person to fool.” —Richard P. Feynman, 1964 | Ben Finney
On Mon, Dec 28, 2009 at 4:17 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Ben Finney writes:
> Instead, the default should be `=='. That is, `Requires-Python: 3' > should be equivalent to `Requires-Python: ==3'; and only "3" or "3.0" or > "3.0.0" etc. will match. I maintain that is what most people will expect > on seeing that syntax.
I really don't think your assessment that a majority agrees with you is warranted. The demand for backward compatibility is so strong that (wearing my maintainer hat, in other projects) I actually assume that in compatibility claims a bare version number like 3 means >= 3.0.0 to my listeners, unless explicitly qualified.
Therefore, I think there should be no default. "Explicit is better than implicit."
I am with Stephen here: If I read "Requires-Python: 3" outloud, it's equivalent to, "my project uses Python 3", and in python-dev, like anywhere else, it includes all versions of Python 3, unless a specific, explicit version is provided.
And IMO the choice of "~=" or "=~" for the range match should be avoided, since that looks like the regexp search operator in Perl, and there "~= 3" would match "3", "3.0.4", and "2.3.5". The next obvious interpretation is "fuzzy match", but that doesn't have an obvious, more specific meaning. The usual comparson operators do have pretty obvious interpretations, and are not hard to use.
I think Antoine's proposal is good (using the range when "2.5" is used, and using 2.5.0 when explicitely needed), and fixes Martin's concerns. So I would be in favor of removing ~= and using Antoine's rule; Regards Tarek
Does that mean we should add "or"?
Requires-Python: 2.5 or 2.6
It would be redundant to have it, since you can also write Requires-Python: >=2.5, <2.7
Should we also use "and" instead of ","?
Requires-Python: >= 2.5 and < 2.6
Perhaps. I think the Linux packaging formats uniformly use the comma. Regards, Martin
Antoine Pitrou writes:
And in fact this case is often more the important one. Packages that depend on having a *recent* version of python will often crash quickly, before doing permanent damage, when an undefined syntax, function, or method is invoked, while packages that depend on a quirk in behavior of an older version will typically silently corrupt data.
How can they know that they depend on "a quirk in behaviour of an older version" if a newer version hasn't been released? This sounds bogus.
Of course a newer version has been released. Who said it hasn't been? Eg, the discussion of <=2.5. Hasn't 2.6 been released? Or am I hallucinating? The point is that some packages depend on >=2.5, and others depend on <=2.5. I see no reason to deprecate the "<=" notation.
It seems to me that all this version range talk relates pretty directly to PEP 386.
The Python version numbers themselves are the simplest type of "Normalized Version"s, and since comparisons of "NormalizedVersion"s are defined in PEP 386, and that's really all we're talking about here, shouldn't this really just follow and reference that document?
That's for the ordering operators (<, <=, >, >=). Tarek absolutely wants a shortcut way of specifying a range, and such a mechanism is not discusses in PEP 386 (other than the conventional >=min,<max, which is not shortcut enough).
Sure we might like some sugar to make expressing ranges simpler, but shouldn't the explicit meanings of any rules be stated in terms of Normalized Version comparisons?
That turns out to be tricky. I agree that the PEP doesn't currently specify it properly (at least, it now says something that Tarek said he didn't want). However, try coming up with wording that says "~=A means >=A and < 'words to describe the proper upper bound'". Regards, Martin
On Mon, Dec 28, 2009 at 10:23 AM, Ben Finney <ben+python@benfinney.id.au> wrote: [..]
So, if no one object, I propose to continue this thread about the way range should be compared, to see if we meet a consensus quite soon. If not, I guess we can go back to distutils-SIG and invite people over there, as we did for other topics.
Please, keep the operators simple and obvious, drawing on the existing conventions in other systems, so there's no need to have bike-shedding discussions over new syntax.
I don't think the operators themselves are the real issue. We've added the ~= operator to address the range isue, but it seems now over-complex for what we really need: The real issue I believe, is to clarify what "2.5" means in the context of defining dependencies and equivalent fields in PEP 345. "2.5" means either "2.5.x", either "2.5.0". And it seems to me that in the common usage, it means "2.5.x". If we agree on this, then Antoine's proposal seems like the natural solution. Regards, Tarek -- Tarek Ziadé | http://ziade.org
And IMO the choice of "~=" or "=~" for the range match should be avoided, since that looks like the regexp search operator in Perl, and there "~= 3" would match "3", "3.0.4", and "2.3.5". The next obvious interpretation is "fuzzy match", but that doesn't have an obvious, more specific meaning. The usual comparson operators do have pretty obvious interpretations, and are not hard to use.
On distutils-sig, a vocal fraction seems to think otherwise. From my short interaction there, I now think that comparison operators are indeed hard to use, and that the concept of a half-open interval, and how you can use relational operators involving the endpoints to denote it, is (apparently) *quite* advanced. More specifically, people fail to notice that saying "X.Y or X.Y+1" still specifies an interval. Being confronted with ">=X.Y, <X.Y+2", they quickly agree that it's equivalent. Regards, Martin
Point of order: what is the point of sending the discussion off to the distutils SIG if we are just going to bikeshed it (again!) here.
Bike-shedding it here is indeed inappropriate. If the PEP had listed all possible arguments that can come up in this discussion, and the corresponding counter arguments, then the discussion should be over. Alas, it seems that the PEP still has open issues, which may mean that distutils-sig didn't finish its work, or that the more general public has different concerns. Wrt. the ~= operator that is now under discussion: I proposed it on distutils-sig, Tarek (eventually) agree, nobody else commented. Now python-dev people neither like the syntax, nor the semantics. Saying that distutils-sig has discussed that aspect would be incorrect, though. Regards, Martin
I think Antoine's proposal is good (using the range when "2.5" is used, and using 2.5.0 when explicitely needed), and fixes Martin's concerns.
So I would be in favor of removing ~= and using Antoine's rule;
So specifying 2.5 would be a short-hand for *what*? Regards, Martin
2009/12/28 "Martin v. Löwis" <martin@v.loewis.de>:
I think Antoine's proposal is good (using the range when "2.5" is used, and using 2.5.0 when explicitely needed), and fixes Martin's concerns.
So I would be in favor of removing ~= and using Antoine's rule;
So specifying 2.5 would be a short-hand for *what*?
2.5 would be a shorthand for 2.5.x. So, equivalent to : >=2.5.0, < 2.6.0 2.5.0 would be the notation required to describe this specific micro version. For third-party projects, the same rule would apply. The only particular point is about projects that don't use the .0 micro notation for the first version of a series. In that case, "2.5" will still mean ">=2.5, < 2.6.0" IOW, if someone needs a full MAJOR.MINOR.MICRO comparison, he will have to explicitely tell if by providing a detailed version, even if he needs to fill it with some ".0"s This will of course be applicable only for PEP 386-compatible versions. So for "Requires-Externals", the range might not apply (as I stated in the PEP) Some examples: Requires-Dist: zope.interface (3.1) ==> any versions that starts with 3.1, not including post- or pre- releases Requires-Dist: zope.interface (3.1.0) ==> only 3.1.0 Requires-Python: 3 ==> Python 3 (no matter wich one) Requires-Python: >=2.6,<3 ==> Any version of Python 2.6.x or 2.7.x (and 2.8.x if it exists one day) Requires-Python: 2.6.2 ==> only Python 2.6.2 Regards Tarek
Another penny dropped when it comes to version specs. Should 2.5 mean 2.5.0 only, or 2.5.*. Well... why would you ever need to specify 2.5.0 only. That's a nonsense specification. "My project requires Python 2.5.0, but doesn't work with 2.5.1". Huh!? Well, then fix it, goofball. :) 2.5 can mean 2.5.* without any problems. And 3 should mean 3.*.*. New suggested spec: versionrequirements ::= 'Requires-Python: ' specificationlist specificationlist ::= specification (; specification)* specification ::= version | "[" [version] ":" [version] "]" version ::= lc_number ["." lc_number [ "." lc_number ] ] With examples being: Requires-Python: [2.5.2:3]; [3.1:] Or on several rows: Requires-Python: [2.5.2:3]; [3.1.2]; [3.2:] Meaning 2.5.2 or later, but not Python 3. *or* Python 3.1.2. *or* Python 3.2 or later. Or if slicing syntax is not wanted: versionrequirements ::= 'Requires-Python: ' specificationlist specificationlist ::= specification (; specification)* specification ::= version | minimum | maximum | miniumum " " maximum minimum ::= ('>' | '>=') version maximum ::= ('<' | '<=') version version ::= lc_number ["." lc_number [ "." lc_number ] ] That would mean something like the following: Requires-Python: >= 2.5.2 < 3; >= 3.1 or more clearer if it's split up in lines: Requires-Python: >= 2.5.2 < 3; >= 3.1 The following would be illegal: Requires-Python: >= 2.5.2 > 3 Requires-Python: <= 2.5.2 < 3 Requires-Python: <= 2.5.2 < 3 > 3.1
Hi Len,
Another penny dropped when it comes to version specs.
Pennies are good. They build value.
With examples being:
Requires-Python: [2.5.2:3]; [3.1:]
What about going even more simple... Requires-Python: 2.5..3 3.1.. If we use double-dots to replace colons, the .. will translate to 'to'. So taking your example more closely might be: Requires-Python: [2.5]..[2.7]; [3.1].. David
On Mon, Dec 28, 2009 at 11:21 AM, Lennart Regebro <regebro@gmail.com> wrote:
Another penny dropped when it comes to version specs.
Should 2.5 mean 2.5.0 only, or 2.5.*. Well... why would you ever need to specify 2.5.0 only. That's a nonsense specification.
"My project requires Python 2.5.0, but doesn't work with 2.5.1". Huh!? Well, then fix it, goofball. :)
2.5 can mean 2.5.* without any problems. And 3 should mean 3.*.*.
I am not sure why you are proposing a new syntax, if you agree that 2.5 should mean 2.5.* The syntax we have specified in the PEP already works with your examples, and is way less complex that your proposals I think. Regards Tarek -- Tarek Ziadé | http://ziade.org
So specifying 2.5 would be a short-hand for *what*?
2.5 would be a shorthand for 2.5.x. So, equivalent to : >=2.5.0, < 2.6.0
Ok, so it's not a shorthand for a single operator anymore, but for a more complex term. Fine with me.
2.5.0 would be the notation required to describe this specific micro version.
I think it would be a shorthand for >=2.5.0, <2.5.1, right? Or are you saying that specifying a version is sometimes a shorthand for a range, and sometimes a shorthand for the == operator (i.e. one exact version)?
Requires-Dist: zope.interface (3.1) ==> any versions that starts with 3.1, not including post- or pre- releases Requires-Dist: zope.interface (3.1.0) ==> only 3.1.0
No, it should be: any version that starts with 3.1.0, not including post- or pre-releases
Requires-Python: 3 ==> Python 3 (no matter wich one)
Almost: excluding pre- and post-releases.
Requires-Python: >=2.6,<3 ==> Any version of Python 2.6.x or 2.7.x (and 2.8.x if it exists one day)
This time, including pre- and post-releases, right?
Requires-Python: 2.6.2 ==> only Python 2.6.2
No: >=2.6.2, <2.6.3 (of course, the only Python release in that range was 2.6.2, since there was no 2.6.2.1). Regards, Martin
Another penny dropped when it comes to version specs.
Should 2.5 mean 2.5.0 only, or 2.5.*. Well... why would you ever need to specify 2.5.0 only. That's a nonsense specification.
"My project requires Python 2.5.0, but doesn't work with 2.5.1". Huh!? Well, then fix it, goofball. :)
This == operator is fairly common in Debian. For example, the apache2 package installed on my system specifies Package: apache2 Version: 2.2.14-4 Depends: apache2-mpm-worker (= 2.2.14-4) | apache2-mpm-prefork (= 2.2.14-4) | apache2-mpm-event (= 2.2.14-4) | apache2-mpm-itk (= 2.2.14-4), apache2.2-common (= 2.2.14-4) So they specify that the packages they need have *exactly* to come from the same build. Otherwise, slight binary incompatibilities may break the thing - and there is no point in risking that. For Python, applications should probably be more tolerant wrt. versioning. However, some people do want to lock dependencies to a specific version, for better reproducability.
The following would be illegal:
Requires-Python: >= 2.5.2 > 3 Requires-Python: <= 2.5.2 < 3 Requires-Python: <= 2.5.2 < 3 > 3.1
-1. I would prefer if there is only a single syntax for specifying version dependencies, independent of what metadata field they appear in. Regards, Martin
On Mon, Dec 28, 2009 at 11:27, <david.lyon@preisshare.net> wrote:
What about going even more simple...
Requires-Python: 2.5..3 3.1..
Doh! Of course. Works for me. In fact, the dots could be dashes as well. Requires-Python: 2.5-3 3.1- Commas, spaces, semicolons, whatever. We could allow: Requires-Python: 2.5-3 3.1- Requires-Python: 2.5-3,3.1- Requires-Python: 2.5-3;3.1- Requires-Python: 2.5..3, 3.1.. To be equivalent. That syntax covers all reasonable usecases, as far as I can see, and is clear. Requires-Python: 2.5.2-3 ,3.1.2, 3.2- 2.5.2 and up to, but not including, 3.0.0. *or* 3.1.2 *or* 3.2.0 or later. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64
2009/12/28 "Martin v. Löwis" <martin@v.loewis.de>: [..]
2.5.0 would be the notation required to describe this specific micro version.
I think it would be a shorthand for >=2.5.0, <2.5.1, right?
Or are you saying that specifying a version is sometimes a shorthand for a range, and sometimes a shorthand for the == operator (i.e. one exact version)?
2.5.0 being a shorthand for >=2.5.0, <2.5.1 is fine with me. [..]
Requires-Dist: zope.interface (3.1.0) ==> only 3.1.0
No, it should be: any version that starts with 3.1.0, not including post- or pre-releases
In practice it means the same if we don't consider going further that the micro version (as I did in my head when providing the examples), but in theory you are right, so that's fine with me.
Requires-Python: 3 ==> Python 3 (no matter wich one)
Almost: excluding pre- and post-releases.
Indeed.
Requires-Python: >=2.6,<3 ==> Any version of Python 2.6.x or 2.7.x (and 2.8.x if it exists one day)
This time, including pre- and post-releases, right?
Which pre- and post-releases exactly in this case ? if you mean 2.6 post- releases, 2.7 and 2.8 pre- and post- releases : yes, they would be included in that range. 3 post-releases are excluded in that case. As a side not: as we said earlier in Distutils-SIG, dealing with specific pre- and -post releases would be a very particular case ppl would have to deal with manually if they are to be founded at the edge of a range. e.g. "<3" doesn't mean Python 3 pre-releases are included.
Requires-Python: 2.6.2 ==> only Python 2.6.2
No: >=2.6.2, <2.6.3 (of course, the only Python release in that range was 2.6.2, since there was no 2.6.2.1).
Sure. If we agree on all of this, I'll add all these examples in the PEP to make it crystal-clear. Regards Tarek
On Mon, Dec 28, 2009 at 11:54, "Martin v. Löwis" <martin@v.loewis.de> wrote:
This == operator is fairly common in Debian. For example, the apache2 package installed on my system specifies
Oh, absolutely, but that's when you specify interdependencies between packages. Nobody makes a Python package for generic use and say "you should only use this with Python 2.5.0 and nothing else". Specifying zope.interfaces 1.2.3 for zope.component 1.2.3 makes a lot of sense, but specifying only Python 2.5.0?
-1. I would prefer if there is only a single syntax for specifying version dependencies, independent of what metadata field they appear in.
That is admittedly a good argument. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64
On Mon, Dec 28, 2009 at 11:57 AM, Lennart Regebro <regebro@gmail.com> wrote:
On Mon, Dec 28, 2009 at 11:27, <david.lyon@preisshare.net> wrote:
What about going even more simple...
Requires-Python: 2.5..3 3.1..
Doh! Of course. Works for me. In fact, the dots could be dashes as well.
Requires-Python: 2.5-3 3.1-
Commas, spaces, semicolons, whatever. We could allow:
Requires-Python: 2.5-3 3.1- Requires-Python: 2.5-3,3.1- Requires-Python: 2.5-3;3.1- Requires-Python: 2.5..3, 3.1..
-1. This looks like typos the developer made on his versions definitions. And if not, is subject to errors by forgetting dashes or dots. Regards, Tarek -- Tarek Ziadé | http://ziade.org
On 12/28/2009 5:42 AM, Martin v. Löwis wrote:
So specifying 2.5 would be a short-hand for *what*?
2.5 would be a shorthand for 2.5.x. So, equivalent to : >=2.5.0, < 2.6.0
Ok, so it's not a shorthand for a single operator anymore, but for a more complex term. Fine with me.
2.5.0 would be the notation required to describe this specific micro version.
I think it would be a shorthand for >=2.5.0, <2.5.1, right?
Actually, the logical extension is that 2.5.0 is shorthand for
=2.5.0.0, <2.5.1.0, I believe.
PEP 386 versions can have an indefinite number of extradecimal versions. Pedantically, -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
On Mon, Dec 28, 2009 at 12:02, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
-1. This looks like typos the developer made on his versions definitions.
Nah.
And if not, is subject to errors by forgetting dashes or dots.
Eh, yeah but that goes for ANY syntax. Having the same syntax as for package specifications does make sense, though. (So we should clearly change that one too, eh?) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Mon, Dec 28, 2009 at 12:04 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Mon, Dec 28, 2009 at 12:02, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
-1. This looks like typos the developer made on his versions definitions.
Nah.
And if not, is subject to errors by forgetting dashes or dots.
Eh, yeah but that goes for ANY syntax.
Having the same syntax as for package specifications does make sense, though. (So we should clearly change that one too, eh?)
I don't think we need to change the syntax in fact. The current one, with simple operators covers the needs as far as I see. What was fuzzy is the meaning of version strings like "2.5". Once it's clarified (and it seems we have a better definition already since a few mails), I think the current syntax works naturally with ranges. Regards Tarek -- Tarek Ziadé | http://ziade.org
On Mon, Dec 28, 2009 at 12:02 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Mon, Dec 28, 2009 at 11:54, "Martin v. Löwis" <martin@v.loewis.de> wrote:
This == operator is fairly common in Debian. For example, the apache2 package installed on my system specifies
Oh, absolutely, but that's when you specify interdependencies between packages. Nobody makes a Python package for generic use and say "you should only use this with Python 2.5.0 and nothing else". Specifying zope.interfaces 1.2.3 for zope.component 1.2.3 makes a lot of sense, but specifying only Python 2.5.0?
It's quite improbable but it could technically happen. For example, let's say I create a third-party project that provides a specific workaround for a bug that was founded in Python 2.5.0 but fixed in Python 2.5.1. IOW defining how versions work should be a set of explicit rules that shouldn't rely on assumptions made on their usage in some specific projects, but rather provides something that covers all needs. Regards, Tarek
Lennart Regebro <regebro@gmail.com> writes:
On Mon, Dec 28, 2009 at 11:54, "Martin v. Löwis" <martin@v.loewis.de> wrote:
This == operator is fairly common in Debian. For example, the apache2 package installed on my system specifies
Oh, absolutely, but that's when you specify interdependencies between packages. Nobody makes a Python package for generic use and say "you should only use this with Python 2.5.0 and nothing else". Specifying zope.interfaces 1.2.3 for zope.component 1.2.3 makes a lot of sense, but specifying only Python 2.5.0?
I'm operating from the principle that there should not be a special syntax that only applies to dependency on the version of Python. The same syntax used for specifying any dependency on any package should also be sufficient for specifying a dependency on Python itself. That being so, the cost in complexity of having a special dependency syntax just for the version of Python should weigh strongly against introducing one. -- \ “First things first, but not necessarily in that order.” —The | `\ Doctor, _Doctor Who_ | _o__) | Ben Finney
How can they know that they depend on "a quirk in behaviour of an older version" if a newer version hasn't been released? This sounds bogus.
Of course a newer version has been released. Who said it hasn't been? Eg, the discussion of <=2.5. Hasn't 2.6 been released? Or am I hallucinating?
So, what you are saying is that software X specifies that it is compatible with "2.5 or later" as long as 2.6 hasn't been released, but when 2.6 is released it switches to "2.5 but not 2.6"?
The point is that some packages depend on >=2.5, and others depend on <=2.5. I see no reason to deprecate the "<=" notation.
That's not really what we are talking IIUC. We are talking about behaviour of "2.5" vs. "2.5.0".
Antoine Pitrou writes:
How can they know that they depend on "a quirk in behaviour of an older version" if a newer version hasn't been released? This sounds bogus.
Of course a newer version has been released. Who said it hasn't been? Eg, the discussion of <=2.5. Hasn't 2.6 been released? Or am I hallucinating?
So, what you are saying is that software X specifies that it is compatible with "2.5 or later" as long as 2.6 hasn't been released, but when 2.6 is released it switches to "2.5 but not 2.6"?
No, I'm not. Let's drop it, as Tarek seems disposed to dismiss the bikeshedding (including this subthread) anyway, which is TheRightThing.
2009/12/28 "Martin v. Löwis" <martin@v.loewis.de>:
Does that mean we should add "or"?
Requires-Python: 2.5 or 2.6
It would be redundant to have it, since you can also write
Requires-Python: >=2.5, <2.7
Should we also use "and" instead of ","?
Requires-Python: >= 2.5 and < 2.6
Perhaps. I think the Linux packaging formats uniformly use the comma.
(I'm picking a somewhat random message to reply to here - in general, I agree with the sentiments expressed in Martin's mail). It seems to me that there's too much of an attempt to invent "do what I mean" semantics, which is complicating the whole issue here. Python prefers "explicit is better than implicit" over the Perl "do what I mean". I don't see why that should be any less the case here. It seems to me that everything people might want to express can be covered with the existing operators, plus comma meaning "and". Maybe some people find "2.5, 2.6" more obvious than ">= 2.5, < 2.7" - but satisfying them at the cost of introducing complexity and ambiguity into the syntax seems to me to be a serious mistake. Paul.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziadé wrote:
2009/12/28 "Martin v. Löwis" <martin@v.loewis.de>:
I think Antoine's proposal is good (using the range when "2.5" is used, and using 2.5.0 when explicitely needed), and fixes Martin's concerns.
So I would be in favor of removing ~= and using Antoine's rule; So specifying 2.5 would be a short-hand for *what*?
2.5 would be a shorthand for 2.5.x. So, equivalent to : >=2.5.0, < 2.6.0
2.5.0 would be the notation required to describe this specific micro version.
For third-party projects, the same rule would apply.
The only particular point is about projects that don't use the .0 micro notation for the first version of a series. In that case, "2.5" will still mean ">=2.5, < 2.6.0"
IOW, if someone needs a full MAJOR.MINOR.MICRO comparison, he will have to explicitely tell if by providing a detailed version, even if he needs to fill it with some ".0"s
This will of course be applicable only for PEP 386-compatible versions. So for "Requires-Externals", the range might not apply (as I stated in the PEP)
Some examples:
Requires-Dist: zope.interface (3.1) ==> any versions that starts with 3.1, not including post- or pre- releases Requires-Dist: zope.interface (3.1.0) ==> only 3.1.0
For completeness, isn't this really "any versino which starts with 3.1.0, not including post- or pre- releases"? That particular pacakge doesn't use more than a third version component, but there are packages in the wild which use four.
Requires-Python: 3 ==> Python 3 (no matter wich one) Requires-Python: >=2.6,<3 ==> Any version of Python 2.6.x or 2.7.x (and 2.8.x if it exists one day) Requires-Python: 2.6.2 ==> only Python 2.6.2
Here, the issue is only theoretical: Python dosn't issue "fourth dot" releases. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks5FHwACgkQ+gerLs4ltQ7LcQCfQPav5l4/lrVrNVUHZuMw6hX/ Rk0An0lBGQ26OOXhO8238EuD/7rGxHUo =Zd6y -----END PGP SIGNATURE-----
On Mon, 28 Dec 2009 10:42:20 +0100, "Martin v. Löwis" <martin@v.loewis.de> wrote:
On distutils-sig, a vocal fraction seems to think otherwise. From my short interaction there, I now think that comparison operators are indeed hard to use, and that the concept of a half-open interval, and how you can use relational operators involving the endpoints to denote it, is (apparently) *quite* advanced.
Absolutely.
From Len and my interactions, I will wrap up and make one addition to the set. I'm adding one last proposition.
Requires-Python: 3
Requires a particular python version.
Requires-Python: 2.5:2.7
Specifies a range of python versions.
Requires-Python: 2.4+
Specifies anything above a particular python version. (No need to ask me about a less than operator. I think a packager would feel more comfortable with using the range operator than a 'less-than' operator. There just comes a point where people don't bother with old interpreter versions) That wraps it up for the vocal faction... Happy new year David
On 28/12/2009 22:57, David Lyon wrote:
On Mon, 28 Dec 2009 10:42:20 +0100, "Martin v. Löwis"<martin@v.loewis.de> wrote:
On distutils-sig, a vocal fraction seems to think otherwise. From my short interaction there, I now think that comparison operators are indeed hard to use, and that the concept of a half-open interval, and how you can use relational operators involving the endpoints to denote it, is (apparently) *quite* advanced.
Absolutely.
From Len and my interactions, I will wrap up and make one addition to the set. I'm adding one last proposition.
Requires-Python: 3
Requires a particular python version.
Requires-Python: 2.5:2.7
Specifies a range of python versions.
So this would work for Python 2.7 but *not* 2.7.1? Or does 2.7 implicitly mean a range of all Python 2.7 versions? If not how do we specify up to the last version of 2.6 (which may not yet be released) but *not* 2.7? 2.5:2.6.9 ? Michael
Requires-Python: 2.4+
Specifies anything above a particular python version.
(No need to ask me about a less than operator. I think a packager would feel more comfortable with using the range operator than a 'less-than' operator. There just comes a point where people don't bother with old interpreter versions)
That wraps it up for the vocal faction...
Happy new year
David
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
On Mon, 28 Dec 2009 23:07:32 +0000, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Requires-Python: 2.5:2.7
Specifies a range of python versions.
So this would work for Python 2.7 but *not* 2.7.1? Or does 2.7 implicitly mean a range of all Python 2.7 versions?
Yes. 2.7 would mean all 2.7 versions. As 2.7.1 is a 2.7 release.
If not how do we specify up to the last version of 2.6 (which may not yet be released) but *not* 2.7?
2.5:2.6.9 ?
No. As you might never know what the last release may ever be as they keep on coming. So like this:
Requires-Python: 2.5:2.6
That will catch all 2.6 unreleased versions (security fixes et la) and not 2.7 David
David Lyon <david.lyon <at> preisshare.net> writes:
Requires a particular python version.
Requires-Python: 2.5:2.7
Why not drop ranges as well as operators and simply use commas? The above would be rewritten as: Requires-Python: 2.5, 2.6, 2.7 This would prevent the ambiguity on the inclusive or exclusive nature of the upper bound of the range. You might argue that if you want to include 8 versions of Python this makes the notation slightly longer, but who tests their package with 8 different versions of Python? (and if you don't test exhaustively, just use the "2.5+" notation) Regards Antoine.
Antoine Pitrou wrote:
David Lyon <david.lyon <at> preisshare.net> writes:
Requires a particular python version.
Requires-Python: 2.5:2.7
Why not drop ranges as well as operators and simply use commas? The above would be rewritten as:
Requires-Python: 2.5, 2.6, 2.7
This would prevent the ambiguity on the inclusive or exclusive nature of the upper bound of the range.
That would mean that commas mean "and" for some entries but "or" for others.
You might argue that if you want to include 8 versions of Python this makes the notation slightly longer, but who tests their package with 8 different versions of Python? (and if you don't test exhaustively, just use the "2.5+" notation)
Wouldn't "2.5+" include "3"? How often would that be used, considering the differences between Python 2.x and Python 3.x?
On Mon, 28 Dec 2009 23:21:54 +0000, Antoine Pitrou <solipsis@pitrou.net> wrote:
David Lyon <david.lyon <at> preisshare.net> writes:
Requires a particular python version.
Requires-Python: 2.5:2.7
Why not drop ranges as well as operators and simply use commas? The above would be rewritten as:
Requires-Python: 2.5, 2.6, 2.7
This would prevent the ambiguity on the inclusive or exclusive nature of the upper bound of the range.
What about specifying that the package works only with, say, 2.6.2 or earlier (because of some problem introduced by 2.6.3)? That could get pretty darn verbose. (Also remember we aren't just talking about the syntax for Python versions, but versions for any package). I do think it is also a valid argument that, from what I've heard here, most extant (linux at least) packaging systems use the >=, etc, operators, so I think talking about changing the proposed syntax radically is probably misplaced. -- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls
R. David Murray <rdmurray <at> bitdance.com> writes:
Why not drop ranges as well as operators and simply use commas? The above would be rewritten as:
Requires-Python: 2.5, 2.6, 2.7
This would prevent the ambiguity on the inclusive or exclusive nature
of the
upper bound of the range.
What about specifying that the package works only with, say, 2.6.2 or earlier (because of some problem introduced by 2.6.3)? That could get pretty darn verbose. (Also remember we aren't just talking about the syntax for Python versions, but versions for any package).
Ok, you're right. Let's drop my proposal then. Regards Antoine.
On Mon, 28 Dec 2009 23:21:54 +0000 (UTC), Antoine Pitrou <solipsis@pitrou.net> wrote:
Requires-Python: 2.5:2.7
Why not drop ranges as well as operators and simply use commas? The above would be rewritten as:
Requires-Python: 2.5, 2.6, 2.7
Firstly, I find your notation proposition to be entirely workable and rational. Len threw in the range notation as a kind of novel idea, but the more I use it, the more that I think it is applicable in this use case. Packages and the interpretor version is about ranges. The choice (for the packager) comes down to either one particular python version (2, 2.x, or 3, or 3.x), or a range of python versions, or a set. There's no reason that I can see why we could not have both, that is a set and a range as Len has suggested. Whether the delineation is with commas or spaces is, to me, is minor.
You might argue that if you want to include 8 versions of Python this makes the notation slightly longer, but who tests their package with 8 different versions of Python?
You're right. The set notation is more obtuse. But with your notation, I hope there would be no problem. For instance:
Requires-Python: 2, 3
To me that would cover all 8 versions. As for the testing thing, well that's the cpan debate.. another thread.
(and if you don't test exhaustively, just use the "2.5+" notation)
Exactly. David
On Mon, 28 Dec 2009 18:55:17 -0500, "R. David Murray" <rdmurray@bitdance.com> wrote:
What about specifying that the package works only with, say, 2.6.2 or earlier (because of some problem introduced by 2.6.3)? That could get pretty darn verbose. (Also remember we aren't just talking about the syntax for Python versions, but versions for any package).
That's why the range operator could be good.
Requires-python: 2.4:2.6.2
I do think it is also a valid argument that, from what I've heard here, most extant (linux at least) packaging systems use the >=, etc, operators, so I think talking about changing the proposed syntax radically is probably misplaced.
The counter argument for 'cloning' the linux packaging system is that most of the representations come from a C perspective. Because of the fact that Linux is predominantly a C product. Since Python isn't C, and doesn't come from C, then one could argue that using short-hand or high level notation is more in keeping with the character of python. So the arguments against the >= == operators come from the desire to keep what looks like C code, *out-of* python packaging. I fully sympathise that some have the desire simply to clone what's already out there. Why make new art when there's a lot of old art already.. The price of doing that is we lose the specific short-handed high-level nature of python. Which is what we were attracted to in the first place. David
David Lyon <david.lyon@preisshare.net> writes:
The counter argument for 'cloning' the linux packaging system is that most of the representations come from a C perspective. Because of the fact that Linux is predominantly a C product.
Since Python isn't C, and doesn't come from C, then one could argue that using short-hand or high level notation is more in keeping with the character of python.
Even if that were true (and it's not at all clear that “Python does not come from C”), that's a classic “not invented here” (NIH) argument. NIH is widely regarded as a very poor reason to reject something that works. The dependency declarations are *not* Python language syntax, and there is no need to consider Python language syntax in defining them. -- \ “When we talk to God, we're praying. When God talks to us, | `\ we're schizophrenic.” —Jane Wagner, via Lily Tomlin, 1985 | _o__) | Ben Finney
On Mon, Dec 28, 2009 at 9:26 PM, Tres Seaver <tseaver@palladion.com> wrote: [..]
Requires-Dist: zope.interface (3.1.0) ==> only 3.1.0
For completeness, isn't this really "any versino which starts with 3.1.0, not including post- or pre- releases"? That particular pacakge doesn't use more than a third version component, but there are packages in the wild which use four.
[..]
Requires-Python: 2.6.2 ==> only Python 2.6.2
Here, the issue is only theoretical: Python dosn't issue "fourth dot" releases.
Both points are right. I'll remove from the PEP the range operator and provide a definition for 2.5 vs 2.5.x vs 2.5.0, as well as all these examples, corrected.
On Dec 28, 2009, at 8:00 PM, Ben Finney wrote:
The dependency declarations are *not* Python language syntax, and there is no need to consider Python language syntax in defining them.
Agreed. We're also not going to be writing an operating system with them; just simple version range statement. I think that the range expression: 2.5:2.7 is easy to read, immediately understandable, and expresses everything that needs to be said. Yes, it needs to be stated that the ends are inclusive, but after that, it's pretty obvious what it means at a glance Steve
David Lyon wrote:
On Mon, 28 Dec 2009 23:07:32 +0000, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Requires-Python: 2.5:2.7
Specifies a range of python versions.
So this would work for Python 2.7 but *not* 2.7.1? Or does 2.7 implicitly mean a range of all Python 2.7 versions?
Yes. 2.7 would mean all 2.7 versions. As 2.7.1 is a 2.7 release.
I suggest that this follow the Python syntax for ranges, where the end is non-inclusive. So "2.5:2.7" would mean "greater than or equal to 2.5, and less than 2.7". Which suggests that "2.5:" could be equivalent to "2.5+", as well as allowing ":3" to mean "any version less than 3.0". Cheers, /larry/
On Tue, Dec 29, 2009 at 2:17 AM, ssteinerX@gmail.com <ssteinerx@gmail.com> wrote:
On Dec 28, 2009, at 8:00 PM, Ben Finney wrote:
The dependency declarations are *not* Python language syntax, and there is no need to consider Python language syntax in defining them.
Agreed.
We're also not going to be writing an operating system with them; just simple version range statement.
I think that the range expression:
2.5:2.7
is easy to read, immediately understandable, and expresses everything that needs to be said.
Yes, it needs to be stated that the ends are inclusive, but after that, it's pretty obvious what it means at a glance
The syntax as it is already defined in the PEP can be used to define what we need. The part that was unclear was about the meaning of "2.5". e.g.: 2.5.0 or 2.5.x.. It became obvious in the thread that it means 2.5.x. (e.g. a range) so there's no need to introduce any range operator, wether it's "~=" or a new notation with ":". IOW, since the syntax already present in the PEP is sufficient for our needs (besides ~=) , and as long as the precise definition of "version string" is provided, I consider that further discussion about the syntax itself is more or less bikeshedding. I am now rewriting the relevant section of the PEP with the examples we discussed in this thread, but the operators should stay the same as they were initially: "<", ">", "<=", ">=", "==" and "!=". Regards Tarek
On Dec 28, 2009, at 8:35 PM, Tarek Ziadé wrote:
On Tue, Dec 29, 2009 at 2:17 AM, ssteinerX@gmail.com <ssteinerx@gmail.com> wrote:
On Dec 28, 2009, at 8:00 PM, Ben Finney wrote:
The dependency declarations are *not* Python language syntax, and there is no need to consider Python language syntax in defining them.
Agreed.
We're also not going to be writing an operating system with them; just simple version range statement.
I think that the range expression:
2.5:2.7
is easy to read, immediately understandable, and expresses everything that needs to be said.
Yes, it needs to be stated that the ends are inclusive, but after that, it's pretty obvious what it means at a glance
The syntax as it is already defined in the PEP can be used to define what we need. The part that was unclear was about the meaning of "2.5". e.g.: 2.5.0 or 2.5.x..
It became obvious in the thread that it means 2.5.x. (e.g. a range) so there's no need to introduce any range operator, wether it's "~=" or a new notation with ":".
IOW, since the syntax already present in the PEP is sufficient for our needs (besides ~=) , and as long as the precise definition of "version string" is provided, I consider that further discussion about the syntax itself is more or less bikeshedding.
I am now rewriting the relevant section of the PEP with the examples we discussed in this thread, but the operators should stay the same as they were initially: "<", ">", "<=", ">=", "==" and "!=".
Fine by me. My original contention was that we should be referencing that document as it already defined everything we needed and that any syntactic sugar be defined in those terms. The ":" syntactic sugar appeals to me but is, as you say, not necessary. S
Tarek Ziadé <ziade.tarek@gmail.com> writes:
I am now rewriting the relevant section of the PEP with the examples we discussed in this thread, but the operators should stay the same as they were initially: "<", ">", "<=", ">=", "==" and "!=".
Thank you, this is the clear and simple path and keeps the dependency declarations in line with existing conventions. -- \ “Let others praise ancient times; I am glad I was born in | `\ these.” —Ovid (43 BCE–18 CE) | _o__) | Ben Finney
On Tue, 29 Dec 2009 12:00:50 +1100, Ben Finney <ben+python@benfinney.id.au> wrote:
The dependency declarations are *not* Python language syntax, and there is no need to consider Python language syntax in defining them.
Well I don't know how you can say that if it is python developers to which all this effort is targeted. David
On Mon, Dec 28, 2009 at 1:15 AM, Tarek Ziade wrote:
This new operator removes the ambiguity the original proposal had, without making it more complex for common use cases. So if you dislike it, you will need to propose something else that also fixes the ambiguity we had.
Ok.
Environment markers .. Here are some example of fields using such markers:
Requires-Dist: pywin32 (>1.0); sys.platform == 'win32'
Requires-Dist: [Windows] pywin32 1.0+ That's simpler, shorter, and less ambiguous. Easier to parse for package managers. David
David Lyon wrote:
On Mon, Dec 28, 2009 at 1:15 AM, Tarek Ziade wrote:
This new operator removes the ambiguity the original proposal had, without making it more complex for common use cases. So if you dislike it, you will need to propose something else that also fixes the ambiguity we had.
Ok.
Environment markers .. Here are some example of fields using such markers:
Requires-Dist: pywin32 (>1.0); sys.platform == 'win32'
Requires-Dist: [Windows] pywin32 1.0+
That's simpler, shorter, and less ambiguous. Easier to parse for package managers.
'win32' is more specific than 'Windows' and, to me, '1.0+' means '>=1.0', not '>1.0'.
Requires-Dist: pywin32 (>1.0); sys.platform == 'win32'
Requires-Dist: [Windows] pywin32 1.0+
That's simpler, shorter, and less ambiguous. Easier to parse for package managers.
Don't you want the PEP to complete? Why this bike-shedding? I can agree it's shorter. I can't agree that it's simpler, or less ambiguous. Regards, Martin
On Jan 3, 2010, at 7:21 PM, Martin v. Löwis wrote:
Requires-Dist: pywin32 (>1.0); sys.platform == 'win32'
Requires-Dist: [Windows] pywin32 1.0+
That's simpler, shorter, and less ambiguous. Easier to parse for package managers.
Don't you want the PEP to complete? Why this bike-shedding?
Really.... Enough, already! S
Hi Martin, Happy New Year,
Requires-Dist: pywin32 (>1.0); sys.platform == 'win32'
Requires-Dist: [Windows] pywin32 1.0+
That's simpler, shorter, and less ambiguous. Easier to parse for package managers.
Don't you want the PEP to complete? Why this bike-shedding?
Well, I'm just helping out by pointing out some simpler ways as Tarek asked me. I was only answering his question. I was out celebrating so it took longer to reply than normal. Bike-Shedding ? Me ? which bikeshed? wanting simple? Anyway, I'm just reading the PEPs and commenting. If there are some alterations that can be done, lets discuss them.
I can agree it's shorter. ..
Cool. What I'd really like is a 'Code-Repository:' keyword so that we can install programs/libraries directly into a system. I feel that this would really simplify the packaging landscape, making it much easier for the scientific community and others to do python software installs. This would allow us to perphaps have something even *more modern* than CPAN. So yes, getting PEP-345 right is important to me. Have a nice day. David
participants (21)
-
"Martin v. Löwis" -
Antoine Pitrou -
Arfrever Frehtes Taifersar Arahesis -
Ben Finney -
David Lyon -
david.lyon＠preisshare.net
-
Fred Drake -
Larry Hastings -
Lennart Regebro -
Michael Foord -
MRAB -
Nick Coghlan -
Paul Moore -
R. David Murray -
Scott Dial -
Sridhar Ratnakumar -
ssteinerX＠gmail.com -
Stephen J. Turnbull -
Tarek Ziadé -
Terry Reedy -
Tres Seaver