Proposing PEP 345 : Metadata for Python Software Packages 1.2
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/f3ba3ecffd20251d73749afbfa636786.jpg?s=120&d=mm&r=g)
Tarek Ziadé wrote:
+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 ---------------------------------------------------------------
![](https://secure.gravatar.com/avatar/1ff2088cf41915b40c7397e0c0a0b660.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nick Coghlan wrote:
Good point. I thought I had done so in the initial editing pass.
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.
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.
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-----
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Wed, Dec 23, 2009 at 3:31 AM, Tres Seaver <tseaver@palladion.com> wrote: [..]
I've done it yesterday.
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
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,
I've changed the layout yesterday, so its easier to read. Regards Tarek -- Tarek Ziadé | http://ziade.org
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Wed, Dec 23, 2009 at 11:18 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote: [..]
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.
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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 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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
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" 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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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).
Please do keep distutils out of PEP 345. The remaining occurrences (such as what the "interpret_marker" function does) should be removed.
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.
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
2009/12/23 "Martin v. Löwis" <martin@v.loewis.de>:
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.
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.
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 ? [..]
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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.
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.
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.
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
2009/12/23 "Martin v. Löwis" <martin@v.loewis.de>:
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. [..]
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.
Ok, I'll remove that part. Regards Tarek -- Tarek Ziadé | http://ziade.org
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
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:
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.
+1
That's a software implementation issue. Not a metadata issue.
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
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
David Lyon writes:
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.
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.)
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
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.
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
David Lyon wrote:
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
![](https://secure.gravatar.com/avatar/f3ba3ecffd20251d73749afbfa636786.jpg?s=120&d=mm&r=g)
Martin v. Löwis wrote:
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 ---------------------------------------------------------------
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 1:15 AM, <david.lyon@preisshare.net> 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". Developers will be able to omit the ~= operator, so they can describe a MAJOR or MAJOR.MINOR version and have the whole range included.
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
![](https://secure.gravatar.com/avatar/db5f70d2f2520ef725839f046bdc32fb.jpg?s=120&d=mm&r=g)
Tarek Ziadé <ziade.tarek <at> gmail.com> writes:
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.
![](https://secure.gravatar.com/avatar/220c78aef1b641b14ae858be084b5373.jpg?s=120&d=mm&r=g)
On Dec 27, 2009, at 8:02 PM, Tarek Ziadé wrote:
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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).
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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
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.
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.
![](https://secure.gravatar.com/avatar/db5f70d2f2520ef725839f046bdc32fb.jpg?s=120&d=mm&r=g)
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.
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Antoine Pitrou writes:
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.
![](https://secure.gravatar.com/avatar/db5f70d2f2520ef725839f046bdc32fb.jpg?s=120&d=mm&r=g)
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".
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
Hi Stephen,
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
![](https://secure.gravatar.com/avatar/d6b9415353e04ffa6de5a8f3aaea0553.jpg?s=120&d=mm&r=g)
On 12/27/2009 7:48 PM, Antoine Pitrou 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.
This "~=" operator looks murkier than it needs to be IMO.
Agreed, though not likely to affect me too much. Terry Jan Reedy
![](https://secure.gravatar.com/avatar/1ff2088cf41915b40c7397e0c0a0b660.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Terry Reedy wrote:
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-----
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 6:16 AM, Tres Seaver <tseaver@palladion.com> wrote:
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
![](https://secure.gravatar.com/avatar/9ff70f96fa67c2a3c80ecf0486138bc2.jpg?s=120&d=mm&r=g)
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.
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 7:39 AM, Lennart Regebro <regebro@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
Hi Martin, Happy New Year,
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
![](https://secure.gravatar.com/avatar/4053d6caab18829c4e8d393b6afa8ad8.jpg?s=120&d=mm&r=g)
On 12/27/2009 4:15 PM, david.lyon@preisshare.net 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? Also, "Requires-Python: 3" would include all 3.X versions, correct? -srid
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar <sridharr@activestate.com> wrote: [..]
<=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
![](https://secure.gravatar.com/avatar/e572da4355c07804e3300bf879ffbe64.jpg?s=120&d=mm&r=g)
Tarek Ziadé <ziade.tarek@gmail.com> writes:
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
![](https://secure.gravatar.com/avatar/4f1bdb13d00c0dc4355e24349d61e107.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Ben Finney writes:
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.
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 4:17 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
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.
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
2009/12/28 "Martin v. Löwis" <martin@v.loewis.de>:
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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)?
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
2009/12/28 "Martin v. Löwis" <martin@v.loewis.de>: [..]
2.5.0 being a shorthand for >=2.5.0, <2.5.1 is fine with me. [..]
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.
Sure. If we agree on all of this, I'll add all these examples in the PEP to make it crystal-clear. Regards Tarek
![](https://secure.gravatar.com/avatar/e5bc599ffbd6e6043182b3237e15ccaa.jpg?s=120&d=mm&r=g)
On 12/28/2009 5:42 AM, Martin v. Löwis wrote:
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
![](https://secure.gravatar.com/avatar/1ff2088cf41915b40c7397e0c0a0b660.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziadé wrote:
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.
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-----
![](https://secure.gravatar.com/avatar/9ff70f96fa67c2a3c80ecf0486138bc2.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/9ff70f96fa67c2a3c80ecf0486138bc2.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 11:57 AM, Lennart Regebro <regebro@gmail.com> wrote:
-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
![](https://secure.gravatar.com/avatar/9ff70f96fa67c2a3c80ecf0486138bc2.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 12:04 PM, Lennart Regebro <regebro@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 11:21 AM, Lennart Regebro <regebro@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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.
-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
![](https://secure.gravatar.com/avatar/9ff70f96fa67c2a3c80ecf0486138bc2.jpg?s=120&d=mm&r=g)
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?
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 12:02 PM, Lennart Regebro <regebro@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/e572da4355c07804e3300bf879ffbe64.jpg?s=120&d=mm&r=g)
Lennart Regebro <regebro@gmail.com> writes:
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
On Mon, 28 Dec 2009 10:42:20 +0100, "Martin v. Löwis" <martin@v.loewis.de> wrote:
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
![](https://secure.gravatar.com/avatar/463a381eaf9c0c08bc130a1bea1874ee.jpg?s=120&d=mm&r=g)
On 28/12/2009 22:57, David Lyon wrote:
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
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
On Mon, 28 Dec 2009 23:07:32 +0000, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Yes. 2.7 would mean all 2.7 versions. As 2.7.1 is a 2.7 release.
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
![](https://secure.gravatar.com/avatar/53c166c5e1f0eef9ff4eb4d0b6ec9371.jpg?s=120&d=mm&r=g)
David Lyon wrote:
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/
![](https://secure.gravatar.com/avatar/db5f70d2f2520ef725839f046bdc32fb.jpg?s=120&d=mm&r=g)
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.
![](https://secure.gravatar.com/avatar/5ce43469c0402a7db8d0cf86fa49da5a.jpg?s=120&d=mm&r=g)
Antoine Pitrou wrote:
That would mean that commas mean "and" for some entries but "or" for others.
Wouldn't "2.5+" include "3"? How often would that be used, considering the differences between Python 2.x and Python 3.x?
![](https://secure.gravatar.com/avatar/f9c4ab38a9ced1923ff1bf6e3553a029.jpg?s=120&d=mm&r=g)
On Mon, 28 Dec 2009 23:21:54 +0000, Antoine Pitrou <solipsis@pitrou.net> 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). 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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
On Mon, 28 Dec 2009 18:55:17 -0500, "R. David Murray" <rdmurray@bitdance.com> wrote:
That's why the range operator could be good.
Requires-python: 2.4:2.6.2
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
![](https://secure.gravatar.com/avatar/e572da4355c07804e3300bf879ffbe64.jpg?s=120&d=mm&r=g)
David Lyon <david.lyon@preisshare.net> writes:
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
![](https://secure.gravatar.com/avatar/220c78aef1b641b14ae858be084b5373.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Tue, Dec 29, 2009 at 2:17 AM, ssteinerX@gmail.com <ssteinerx@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/220c78aef1b641b14ae858be084b5373.jpg?s=120&d=mm&r=g)
On Dec 28, 2009, at 8:35 PM, Tarek Ziadé wrote:
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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
On Mon, 28 Dec 2009 23:21:54 +0000 (UTC), Antoine Pitrou <solipsis@pitrou.net> wrote:
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'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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/5ce43469c0402a7db8d0cf86fa49da5a.jpg?s=120&d=mm&r=g)
Tarek Ziadé wrote:
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.
![](https://secure.gravatar.com/avatar/4053d6caab18829c4e8d393b6afa8ad8.jpg?s=120&d=mm&r=g)
On 12/27/2009 5:21 PM, MRAB wrote:
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:
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
![](https://secure.gravatar.com/avatar/1ff2088cf41915b40c7397e0c0a0b660.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziadé wrote:
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-----
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 6:20 AM, Tres Seaver <tseaver@palladion.com> wrote:
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
![](https://secure.gravatar.com/avatar/e572da4355c07804e3300bf879ffbe64.jpg?s=120&d=mm&r=g)
Tarek Ziadé <ziade.tarek@gmail.com> writes:
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.
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 10:23 AM, Ben Finney <ben+python@benfinney.id.au> wrote: [..]
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 3:03 AM, MRAB <python@mrabarnett.plus.com> wrote:
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/d995b462a98fea412efa79d17ba3787a.jpg?s=120&d=mm&r=g)
2009/12/28 "Martin v. Löwis" <martin@v.loewis.de>:
(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.
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
david.lyon@preisshare.net writes:
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
david.lyon@preisshare.net wrote:
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
![](https://secure.gravatar.com/avatar/e572da4355c07804e3300bf879ffbe64.jpg?s=120&d=mm&r=g)
Tarek Ziadé <ziade.tarek@gmail.com> writes:
-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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
As an application developer, I really stand with Tarek here.
Not sure what specific point of Tarek you are supporting, though.
That's my point, not Tarek's, though (the text you quote and that you seem to object to is from Tarek).
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).
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
![](https://secure.gravatar.com/avatar/f3ba3ecffd20251d73749afbfa636786.jpg?s=120&d=mm&r=g)
Tarek Ziadé wrote:
+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 ---------------------------------------------------------------
![](https://secure.gravatar.com/avatar/1ff2088cf41915b40c7397e0c0a0b660.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nick Coghlan wrote:
Good point. I thought I had done so in the initial editing pass.
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.
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.
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-----
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Wed, Dec 23, 2009 at 3:31 AM, Tres Seaver <tseaver@palladion.com> wrote: [..]
I've done it yesterday.
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
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,
I've changed the layout yesterday, so its easier to read. Regards Tarek -- Tarek Ziadé | http://ziade.org
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Wed, Dec 23, 2009 at 11:18 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote: [..]
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.
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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 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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
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" 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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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).
Please do keep distutils out of PEP 345. The remaining occurrences (such as what the "interpret_marker" function does) should be removed.
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.
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
2009/12/23 "Martin v. Löwis" <martin@v.loewis.de>:
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.
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.
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 ? [..]
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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.
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.
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.
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
2009/12/23 "Martin v. Löwis" <martin@v.loewis.de>:
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. [..]
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.
Ok, I'll remove that part. Regards Tarek -- Tarek Ziadé | http://ziade.org
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
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:
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.
+1
That's a software implementation issue. Not a metadata issue.
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
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
David Lyon writes:
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.
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.)
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
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.
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
David Lyon wrote:
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
![](https://secure.gravatar.com/avatar/f3ba3ecffd20251d73749afbfa636786.jpg?s=120&d=mm&r=g)
Martin v. Löwis wrote:
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 ---------------------------------------------------------------
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 1:15 AM, <david.lyon@preisshare.net> 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". Developers will be able to omit the ~= operator, so they can describe a MAJOR or MAJOR.MINOR version and have the whole range included.
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
![](https://secure.gravatar.com/avatar/db5f70d2f2520ef725839f046bdc32fb.jpg?s=120&d=mm&r=g)
Tarek Ziadé <ziade.tarek <at> gmail.com> writes:
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.
![](https://secure.gravatar.com/avatar/220c78aef1b641b14ae858be084b5373.jpg?s=120&d=mm&r=g)
On Dec 27, 2009, at 8:02 PM, Tarek Ziadé wrote:
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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).
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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
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.
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.
![](https://secure.gravatar.com/avatar/db5f70d2f2520ef725839f046bdc32fb.jpg?s=120&d=mm&r=g)
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.
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Antoine Pitrou writes:
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.
![](https://secure.gravatar.com/avatar/db5f70d2f2520ef725839f046bdc32fb.jpg?s=120&d=mm&r=g)
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".
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
Hi Stephen,
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
![](https://secure.gravatar.com/avatar/d6b9415353e04ffa6de5a8f3aaea0553.jpg?s=120&d=mm&r=g)
On 12/27/2009 7:48 PM, Antoine Pitrou 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.
This "~=" operator looks murkier than it needs to be IMO.
Agreed, though not likely to affect me too much. Terry Jan Reedy
![](https://secure.gravatar.com/avatar/1ff2088cf41915b40c7397e0c0a0b660.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Terry Reedy wrote:
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-----
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 6:16 AM, Tres Seaver <tseaver@palladion.com> wrote:
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
![](https://secure.gravatar.com/avatar/9ff70f96fa67c2a3c80ecf0486138bc2.jpg?s=120&d=mm&r=g)
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.
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 7:39 AM, Lennart Regebro <regebro@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
Hi Martin, Happy New Year,
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
![](https://secure.gravatar.com/avatar/4053d6caab18829c4e8d393b6afa8ad8.jpg?s=120&d=mm&r=g)
On 12/27/2009 4:15 PM, david.lyon@preisshare.net 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? Also, "Requires-Python: 3" would include all 3.X versions, correct? -srid
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar <sridharr@activestate.com> wrote: [..]
<=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
![](https://secure.gravatar.com/avatar/e572da4355c07804e3300bf879ffbe64.jpg?s=120&d=mm&r=g)
Tarek Ziadé <ziade.tarek@gmail.com> writes:
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
![](https://secure.gravatar.com/avatar/4f1bdb13d00c0dc4355e24349d61e107.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
Ben Finney writes:
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.
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 4:17 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
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.
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
2009/12/28 "Martin v. Löwis" <martin@v.loewis.de>:
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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)?
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
2009/12/28 "Martin v. Löwis" <martin@v.loewis.de>: [..]
2.5.0 being a shorthand for >=2.5.0, <2.5.1 is fine with me. [..]
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.
Sure. If we agree on all of this, I'll add all these examples in the PEP to make it crystal-clear. Regards Tarek
![](https://secure.gravatar.com/avatar/e5bc599ffbd6e6043182b3237e15ccaa.jpg?s=120&d=mm&r=g)
On 12/28/2009 5:42 AM, Martin v. Löwis wrote:
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
![](https://secure.gravatar.com/avatar/1ff2088cf41915b40c7397e0c0a0b660.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziadé wrote:
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.
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-----
![](https://secure.gravatar.com/avatar/9ff70f96fa67c2a3c80ecf0486138bc2.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/9ff70f96fa67c2a3c80ecf0486138bc2.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 11:57 AM, Lennart Regebro <regebro@gmail.com> wrote:
-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
![](https://secure.gravatar.com/avatar/9ff70f96fa67c2a3c80ecf0486138bc2.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 12:04 PM, Lennart Regebro <regebro@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 11:21 AM, Lennart Regebro <regebro@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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.
-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
![](https://secure.gravatar.com/avatar/9ff70f96fa67c2a3c80ecf0486138bc2.jpg?s=120&d=mm&r=g)
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?
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 12:02 PM, Lennart Regebro <regebro@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/e572da4355c07804e3300bf879ffbe64.jpg?s=120&d=mm&r=g)
Lennart Regebro <regebro@gmail.com> writes:
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
On Mon, 28 Dec 2009 10:42:20 +0100, "Martin v. Löwis" <martin@v.loewis.de> wrote:
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
![](https://secure.gravatar.com/avatar/463a381eaf9c0c08bc130a1bea1874ee.jpg?s=120&d=mm&r=g)
On 28/12/2009 22:57, David Lyon wrote:
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
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
On Mon, 28 Dec 2009 23:07:32 +0000, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Yes. 2.7 would mean all 2.7 versions. As 2.7.1 is a 2.7 release.
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
![](https://secure.gravatar.com/avatar/53c166c5e1f0eef9ff4eb4d0b6ec9371.jpg?s=120&d=mm&r=g)
David Lyon wrote:
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/
![](https://secure.gravatar.com/avatar/db5f70d2f2520ef725839f046bdc32fb.jpg?s=120&d=mm&r=g)
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.
![](https://secure.gravatar.com/avatar/5ce43469c0402a7db8d0cf86fa49da5a.jpg?s=120&d=mm&r=g)
Antoine Pitrou wrote:
That would mean that commas mean "and" for some entries but "or" for others.
Wouldn't "2.5+" include "3"? How often would that be used, considering the differences between Python 2.x and Python 3.x?
![](https://secure.gravatar.com/avatar/f9c4ab38a9ced1923ff1bf6e3553a029.jpg?s=120&d=mm&r=g)
On Mon, 28 Dec 2009 23:21:54 +0000, Antoine Pitrou <solipsis@pitrou.net> 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). 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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
On Mon, 28 Dec 2009 18:55:17 -0500, "R. David Murray" <rdmurray@bitdance.com> wrote:
That's why the range operator could be good.
Requires-python: 2.4:2.6.2
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
![](https://secure.gravatar.com/avatar/e572da4355c07804e3300bf879ffbe64.jpg?s=120&d=mm&r=g)
David Lyon <david.lyon@preisshare.net> writes:
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
![](https://secure.gravatar.com/avatar/220c78aef1b641b14ae858be084b5373.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Tue, Dec 29, 2009 at 2:17 AM, ssteinerX@gmail.com <ssteinerx@gmail.com> wrote:
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
![](https://secure.gravatar.com/avatar/220c78aef1b641b14ae858be084b5373.jpg?s=120&d=mm&r=g)
On Dec 28, 2009, at 8:35 PM, Tarek Ziadé wrote:
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
![](https://secure.gravatar.com/avatar/e572da4355c07804e3300bf879ffbe64.jpg?s=120&d=mm&r=g)
Tarek Ziadé <ziade.tarek@gmail.com> writes:
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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
On Mon, 28 Dec 2009 23:21:54 +0000 (UTC), Antoine Pitrou <solipsis@pitrou.net> wrote:
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'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
![](https://secure.gravatar.com/avatar/b264e73c1ffddd01346a811dbaff18a4.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/5ce43469c0402a7db8d0cf86fa49da5a.jpg?s=120&d=mm&r=g)
Tarek Ziadé wrote:
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.
![](https://secure.gravatar.com/avatar/4053d6caab18829c4e8d393b6afa8ad8.jpg?s=120&d=mm&r=g)
On 12/27/2009 5:21 PM, MRAB wrote:
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:
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
![](https://secure.gravatar.com/avatar/1ff2088cf41915b40c7397e0c0a0b660.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziadé wrote:
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-----
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 6:20 AM, Tres Seaver <tseaver@palladion.com> wrote:
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
![](https://secure.gravatar.com/avatar/e572da4355c07804e3300bf879ffbe64.jpg?s=120&d=mm&r=g)
Tarek Ziadé <ziade.tarek@gmail.com> writes:
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.
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 10:23 AM, Ben Finney <ben+python@benfinney.id.au> wrote: [..]
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/5e5142d6a1a578f02e2d94c4d6d31088.jpg?s=120&d=mm&r=g)
On Mon, Dec 28, 2009 at 3:03 AM, MRAB <python@mrabarnett.plus.com> wrote:
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/d995b462a98fea412efa79d17ba3787a.jpg?s=120&d=mm&r=g)
2009/12/28 "Martin v. Löwis" <martin@v.loewis.de>:
(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.
![](https://secure.gravatar.com/avatar/334b870d5b26878a79b2dc4cfcc500bc.jpg?s=120&d=mm&r=g)
david.lyon@preisshare.net writes:
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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
david.lyon@preisshare.net wrote:
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
![](https://secure.gravatar.com/avatar/e572da4355c07804e3300bf879ffbe64.jpg?s=120&d=mm&r=g)
Tarek Ziadé <ziade.tarek@gmail.com> writes:
-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
![](https://secure.gravatar.com/avatar/3acb8bae5a2b5a28f6fe522a4ea9b873.jpg?s=120&d=mm&r=g)
As an application developer, I really stand with Tarek here.
Not sure what specific point of Tarek you are supporting, though.
That's my point, not Tarek's, though (the text you quote and that you seem to object to is from Tarek).
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).
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
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