Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
Hi Stephen, > BTW, *all* of the Python applications I really care about make a point > of specifying a range of versions they work with (or bundle a > particular version). Yes, well that was my point exactly. If opinion is against commas, then we can take them out. That would give us something like: Requires-python: 2.5 2.6 2.7 3 That would specify a bundle of versions. Processing that only requires the string split() function. If we were to adds Lens suggestion of the range indicator that would simplify things even more. Requires-python: 2.5:2.7 3 That would specify everything between 2.5 and 2.7 and then everything in the 3 series. This would make it very simple. David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, Dec 28, 2009 at 7:39 AM, Lennart Regebro wrote: > On Mon, Dec 28, 2009 at 05:37, Terry Reedy wrote: >> If the first x.y release were called x.y.0, (does not sys.version include >> 0?) then x.y would unambiguously mean the series. > > Yeah, well, although sys.version includes the zero, nothing else does. > The first releases are called 2.5, which is ambiguous. Both Python and > Plone leaves out the zero in the version name. IMO that's a bug. But > that's now how it is. Yes but in PEP 386 semantics, 2.5 will be equivalent to 2.5.0, so it doesn't matter if a software doesn't use the .0 Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, Dec 28, 2009 at 6:20 AM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Tarek Ziadé wrote: >> On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar >> wrote: >> [..] >>> Tarek, >>> >>> I am a bit confused at the current proposal combined with the newly >>> introduced range operator. >>> >>> Would "Requires-Python: <=2.5" include 2.5.4 or not? >> >> <=2.5 means any version that is inferior or equal to 2.5.0 so 2.5.4 >> doesn't match >> >>> Also, "Requires-Python: 3" would include all 3.X versions, correct? >> >> Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= >> 3" >> which is equivalent to "Requires-Python: 3.x.x" >> > > Point of order: what is the point of sending the discussion off to the > distutils SIG if we are just going to bikeshed it (again!) here. What happened is that Martin came late in the discussions in Distutils-SIG after I've forwarded the final mail in Catalog-SIG and after I did send it here (the mail where I said "Here's the mail I'll send to python-dev for PEP 345, if anyone sees a problem or something to add") I agree that the comma and syntax discussions are bikeshedding. Although I don't think the range discussion is bikeshedding, and so far we made some progress on clarifying how range versions are compared in that PEP through Martin's points and this thread. It's quite important IMHO to clarify it. So, if no one object, I propose to continue this thread about the way range should be compared, to see if we meet a consensus quite soon. If not, I guess we can go back to distutils-SIG and invite people over there, as we did for other topics. Regards, Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, Dec 28, 2009 at 6:16 AM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Terry Reedy wrote: >> On 12/27/2009 7:48 PM, Antoine Pitrou wrote: >>> Tarek Ziadé gmail.com> writes: This was ambiguous because it was unclear, as MvL stated, if "2.5" was just "2.5.0" or included versions like "2.5.1" or "2.5.2". >>> How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5 >>> itself? (ditto for "2.5.N" matching only 2.5.N for N>= 1) >> >> If the first x.y release were called x.y.0, (does not sys.version >> include 0?) then x.y would unambiguously mean the series. > > This syntax is not just for the 'Requires-Python:' field, but also for > the 'Requires-Dist:' and 'Obsoletes-Dist:' fields: not all third-party > packages call the first release of a given series .0. They do start with "2.5" *or* "2.5.0" for their first release of the 2.5 series. And both are equal for PEP 386. IOW "2.5 == 2.5.0", always. So it doesn't really matter if some projects don't use the terminal 0 here. Antoine's proposal still works. Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, Dec 28, 2009 at 3:03 AM, MRAB wrote: > Martin v. Löwis wrote: >>> >>> No application developer will quickly figure out what a tilde means. >>> Maybe >>> it means 'roughly', but it requires too much thought and is ambiguous. >>> 2.5 >>> is not roughly 2.5.2. It is the same exactly. >>> >>> Before we had : Requires-Python: 2.5, 2.6 >>> >>> That made much more sense. It was simple and unambiguous, and is relevant >>> to typical packaging scenarios. >> >> Unfortunately, it is fairly ambiguous, and makes no sense. It means >> "requires Python 2.5 *AND* requires Python 2.6", which is a requirement >> that no single version can meet. >> > Does that mean we should add "or"? > > Requires-Python: 2.5 or 2.6 > > Should we also use "and" instead of ","? > > Requires-Python: >= 2.5 and < 2.6 This was discussed aready in Ditsutils-SIG : *and* is enough to express everything, so for the sake of simplicity, the comma means *and* all the time, as Mentioned in http://www.python.org/dev/peps/pep-0345/#version-specifiers Regards Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
david.l...@preisshare.net wrote: >>> No application developer will quickly figure out what a tilde means. >>> Maybe >>> it means 'roughly', but it requires too much thought and is ambiguous. >>> 2.5 >>> is not roughly 2.5.2. It is the same exactly. >>> >>> Before we had : Requires-Python: 2.5, 2.6 >>> >>> That made much more sense. It was simple and unambiguous, and is >>> relevant >>> to typical packaging scenarios. >> Unfortunately, it is fairly ambiguous, and makes no sense. It means >> "requires Python 2.5 *AND* requires Python 2.6", which is a requirement >> that no single version can meet. > > No, it means a library requires either python 2.5 *OR* python 2.6 to be > installed properly. Well, the PEP says that the comma means "and", see http://www.python.org/dev/peps/pep-0345/#version-specifiers If the comma would mean "or", then what would ">1.0, !=1.3.4, <2.0" mean? above 1.0 OR unequal to 1.3.4 OR below 2.0 That would mean that *any* version would match that spec, and then the spec would be meaningless. If that's not clear, ask whether 4.0 would match: yes, it would, because it's >1.0. What about 0.9: yes, it's <2.0. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
Antoine Pitrou writes: > > > And in fact this case is often more the important one. Packages that > > depend on having a *recent* version of python will often crash > > quickly, before doing permanent damage, when an undefined syntax, > > function, or method is invoked, while packages that depend on a quirk > > in behavior of an older version will typically silently corrupt data. > > How can they know that they depend on "a quirk in behaviour of an older > version" if a newer version hasn't been released? This sounds bogus. Of course a newer version has been released. Who said it hasn't been? Eg, the discussion of <=2.5. Hasn't 2.6 been released? Or am I hallucinating? The point is that some packages depend on >=2.5, and others depend on <=2.5. I see no reason to deprecate the "<=" notation. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, Dec 28, 2009 at 4:17 AM, Stephen J. Turnbull wrote: > Ben Finney writes: > > > Instead, the default should be `=='. That is, `Requires-Python: 3' > > should be equivalent to `Requires-Python: ==3'; and only "3" or "3.0" or > > "3.0.0" etc. will match. I maintain that is what most people will expect > > on seeing that syntax. > > I really don't think your assessment that a majority agrees with you > is warranted. The demand for backward compatibility is so strong that > (wearing my maintainer hat, in other projects) I actually assume that > in compatibility claims a bare version number like 3 means >= 3.0.0 to > my listeners, unless explicitly qualified. > > Therefore, I think there should be no default. "Explicit is better > than implicit." I am with Stephen here: If I read "Requires-Python: 3" outloud, it's equivalent to, "my project uses Python 3", and in python-dev, like anywhere else, it includes all versions of Python 3, unless a specific, explicit version is provided. > > And IMO the choice of "~=" or "=~" for the range match should be > avoided, since that looks like the regexp search operator in Perl, and > there "~= 3" would match "3", "3.0.4", and "2.3.5". The next obvious > interpretation is "fuzzy match", but that doesn't have an obvious, > more specific meaning. The usual comparson operators do have pretty > obvious interpretations, and are not hard to use. I think Antoine's proposal is good (using the range when "2.5" is used, and using 2.5.0 when explicitely needed), and fixes Martin's concerns. So I would be in favor of removing ~= and using Antoine's rule; Regards Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
Tarek Ziadé writes: > What happened is that Martin came late in the discussions in > Distutils-SIG after I've forwarded the final mail in Catalog-SIG and > after I did send it here (the mail where I said "Here's the mail I'll > send to python-dev for PEP 345, if anyone sees a problem or something > to add") I was under the impression that previous art was being followed in the area of specifying dependencies. That previous art being the many existing dependency systems, which use obvious comparison operators (the ‘>’ ‘>=’ ‘<’ ‘<=’) and no range operators or implicit ranges. > So, if no one object, I propose to continue this thread about the way > range should be compared, to see if we meet a consensus quite soon. If > not, I guess we can go back to distutils-SIG and invite people over > there, as we did for other topics. Please, keep the operators simple and obvious, drawing on the existing conventions in other systems, so there's no need to have bike-shedding discussions over new syntax. -- \ “Science is a way of trying not to fool yourself. The first | `\ principle is that you must not fool yourself, and you are the | _o__) easiest person to fool.” —Richard P. Feynman, 1964 | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
> 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
> It seems to me that all this version range talk relates pretty > directly to PEP 386. > > The Python version numbers themselves are the simplest type of > "Normalized Version"s, and since comparisons of "NormalizedVersion"s > are defined in PEP 386, and that's really all we're talking about > here, shouldn't this really just follow and reference that document? That's for the ordering operators (<, <=, >, >=). Tarek absolutely wants a shortcut way of specifying a range, and such a mechanism is not discusses in PEP 386 (other than the conventional >=min, Sure we might like some sugar to make expressing ranges simpler, but > shouldn't the explicit meanings of any rules be stated in terms of > Normalized Version comparisons? That turns out to be tricky. I agree that the PEP doesn't currently specify it properly (at least, it now says something that Tarek said he didn't want). However, try coming up with wording that says "~=A means >=A and < 'words to describe the proper upper bound'". Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, Dec 28, 2009 at 10:23 AM, Ben Finney wrote: [..] >> So, if no one object, I propose to continue this thread about the way >> range should be compared, to see if we meet a consensus quite soon. If >> not, I guess we can go back to distutils-SIG and invite people over >> there, as we did for other topics. > > Please, keep the operators simple and obvious, drawing on the existing > conventions in other systems, so there's no need to have bike-shedding > discussions over new syntax. I don't think the operators themselves are the real issue. We've added the ~= operator to address the range isue, but it seems now over-complex for what we really need: The real issue I believe, is to clarify what "2.5" means in the context of defining dependencies and equivalent fields in PEP 345. "2.5" means either "2.5.x", either "2.5.0". And it seems to me that in the common usage, it means "2.5.x". If we agree on this, then Antoine's proposal seems like the natural solution. Regards, Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
> And IMO the choice of "~=" or "=~" for the range match should be > avoided, since that looks like the regexp search operator in Perl, and > there "~= 3" would match "3", "3.0.4", and "2.3.5". The next obvious > interpretation is "fuzzy match", but that doesn't have an obvious, > more specific meaning. The usual comparson operators do have pretty > obvious interpretations, and are not hard to use. On distutils-sig, a vocal fraction seems to think otherwise. From my short interaction there, I now think that comparison operators are indeed hard to use, and that the concept of a half-open interval, and how you can use relational operators involving the endpoints to denote it, is (apparently) *quite* advanced. More specifically, people fail to notice that saying "X.Y or X.Y+1" still specifies an interval. Being confronted with ">=X.Y, http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
> 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
> I think Antoine's proposal is good (using the range when "2.5" is > used, and using 2.5.0 when explicitely > needed), and fixes Martin's concerns. > > So I would be in favor of removing ~= and using Antoine's rule; So specifying 2.5 would be a short-hand for *what*? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
2009/12/28 "Martin v. Löwis" : >> I think Antoine's proposal is good (using the range when "2.5" is >> used, and using 2.5.0 when explicitely >> needed), and fixes Martin's concerns. >> >> So I would be in favor of removing ~= and using Antoine's rule; > > So specifying 2.5 would be a short-hand for *what*? 2.5 would be a shorthand for 2.5.x. So, equivalent to : >=2.5.0, < 2.6.0 2.5.0 would be the notation required to describe this specific micro version. For third-party projects, the same rule would apply. The only particular point is about projects that don't use the .0 micro notation for the first version of a series. In that case, "2.5" will still mean ">=2.5, < 2.6.0" IOW, if someone needs a full MAJOR.MINOR.MICRO comparison, he will have to explicitely tell if by providing a detailed version, even if he needs to fill it with some ".0"s This will of course be applicable only for PEP 386-compatible versions. So for "Requires-Externals", the range might not apply (as I stated in the PEP) Some examples: Requires-Dist: zope.interface (3.1) ==> any versions that starts with 3.1, not including post- or pre- releases Requires-Dist: zope.interface (3.1.0) ==> only 3.1.0 Requires-Python: 3 ==> Python 3 (no matter wich one) Requires-Python: >=2.6,<3 ==> Any version of Python 2.6.x or 2.7.x (and 2.8.x if it exists one day) Requires-Python: 2.6.2 ==> only Python 2.6.2 Regards Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, Dec 28, 2009 at 11:21 AM, Lennart Regebro wrote: > Another penny dropped when it comes to version specs. > > Should 2.5 mean 2.5.0 only, or 2.5.*. Well... why would you ever need > to specify 2.5.0 only. That's a nonsense specification. > > "My project requires Python 2.5.0, but doesn't work with 2.5.1". Huh!? > Well, then fix it, goofball. :) > > 2.5 can mean 2.5.* without any problems. And 3 should mean 3.*.*. I am not sure why you are proposing a new syntax, if you agree that 2.5 should mean 2.5.* The syntax we have specified in the PEP already works with your examples, and is way less complex that your proposals I think. Regards Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
>> So specifying 2.5 would be a short-hand for *what*? > > 2.5 would be a shorthand for 2.5.x. So, equivalent to : >=2.5.0, < 2.6.0 Ok, so it's not a shorthand for a single operator anymore, but for a more complex term. Fine with me. > 2.5.0 would be the notation required to describe this specific micro version. I think it would be a shorthand for >=2.5.0, <2.5.1, right? Or are you saying that specifying a version is sometimes a shorthand for a range, and sometimes a shorthand for the == operator (i.e. one exact version)? > Requires-Dist: zope.interface (3.1) ==> any versions that starts > with 3.1, not including post- or pre- releases > Requires-Dist: zope.interface (3.1.0) ==> only 3.1.0 No, it should be: any version that starts with 3.1.0, not including post- or pre-releases > Requires-Python: 3 ==> Python 3 (no > matter wich one) Almost: excluding pre- and post-releases. > Requires-Python: >=2.6,<3 ==> Any version of Python > 2.6.x or 2.7.x (and 2.8.x if it exists one day) This time, including pre- and post-releases, right? > Requires-Python: 2.6.2 ==> only Python 2.6.2 No: >=2.6.2, <2.6.3 (of course, the only Python release in that range was 2.6.2, since there was no 2.6.2.1). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
> Another penny dropped when it comes to version specs. > > Should 2.5 mean 2.5.0 only, or 2.5.*. Well... why would you ever need > to specify 2.5.0 only. That's a nonsense specification. > > "My project requires Python 2.5.0, but doesn't work with 2.5.1". Huh!? > Well, then fix it, goofball. :) This == operator is fairly common in Debian. For example, the apache2 package installed on my system specifies Package: apache2 Version: 2.2.14-4 Depends: apache2-mpm-worker (= 2.2.14-4) | apache2-mpm-prefork (= 2.2.14-4) | apache2-mpm-event (= 2.2.14-4) | apache2-mpm-itk (= 2.2.14-4), apache2.2-common (= 2.2.14-4) So they specify that the packages they need have *exactly* to come from the same build. Otherwise, slight binary incompatibilities may break the thing - and there is no point in risking that. For Python, applications should probably be more tolerant wrt. versioning. However, some people do want to lock dependencies to a specific version, for better reproducability. > The following would be illegal: > > Requires-Python: >= 2.5.2 > 3 > Requires-Python: <= 2.5.2 < 3 > Requires-Python: <= 2.5.2 < 3 > 3.1 -1. I would prefer if there is only a single syntax for specifying version dependencies, independent of what metadata field they appear in. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, Dec 28, 2009 at 11:27, 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
2009/12/28 "Martin v. Löwis" : [..] >> 2.5.0 would be the notation required to describe this specific micro version. > > I think it would be a shorthand for >=2.5.0, <2.5.1, right? > > Or are you saying that specifying a version is sometimes a shorthand for > a range, and sometimes a shorthand for the == operator (i.e. one exact > version)? 2.5.0 being a shorthand for >=2.5.0, <2.5.1 is fine with me. [..] >> Requires-Dist: zope.interface (3.1.0) ==> only 3.1.0 > > No, it should be: any version that starts with 3.1.0, not including > post- or pre-releases In practice it means the same if we don't consider going further that the micro version (as I did in my head when providing the examples), but in theory you are right, so that's fine with me. >> Requires-Python: 3 ==> Python 3 (no matter wich >> one) > > Almost: excluding pre- and post-releases. Indeed. > >> Requires-Python: >=2.6,<3 ==> Any version of Python 2.6.x >> or 2.7.x (and 2.8.x if it exists one day) > > This time, including pre- and post-releases, right? Which pre- and post-releases exactly in this case ? if you mean 2.6 post- releases, 2.7 and 2.8 pre- and post- releases : yes, they would be included in that range. 3 post-releases are excluded in that case. As a side not: as we said earlier in Distutils-SIG, dealing with specific pre- and -post releases would be a very particular case ppl would have to deal with manually if they are to be founded at the edge of a range. e.g. "<3" doesn't mean Python 3 pre-releases are included. >> Requires-Python: 2.6.2 ==> only Python 2.6.2 > > No: >=2.6.2, <2.6.3 (of course, the only Python release in that range > was 2.6.2, since there was no 2.6.2.1). Sure. If we agree on all of this, I'll add all these examples in the PEP to make it crystal-clear. Regards Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, Dec 28, 2009 at 11:54, "Martin v. Löwis" wrote: > This == operator is fairly common in Debian. For example, the apache2 > package installed on my system specifies Oh, absolutely, but that's when you specify interdependencies between packages. Nobody makes a Python package for generic use and say "you should only use this with Python 2.5.0 and nothing else". Specifying zope.interfaces 1.2.3 for zope.component 1.2.3 makes a lot of sense, but specifying only Python 2.5.0? > -1. I would prefer if there is only a single syntax for specifying > version dependencies, independent of what metadata field they > appear in. That is admittedly a good argument. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, Dec 28, 2009 at 11:57 AM, Lennart Regebro wrote: > On Mon, Dec 28, 2009 at 11:27, wrote: >> What about going even more simple... >> >> Requires-Python: 2.5..3 3.1.. > > Doh! Of course. Works for me. In fact, the dots could be dashes as well. > > Requires-Python: 2.5-3 3.1- > > Commas, spaces, semicolons, whatever. We could allow: > > Requires-Python: 2.5-3 3.1- > Requires-Python: 2.5-3,3.1- > Requires-Python: 2.5-3;3.1- > Requires-Python: 2.5..3, 3.1.. -1. This looks like typos the developer made on his versions definitions. And if not, is subject to errors by forgetting dashes or dots. Regards, Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On 12/28/2009 5:42 AM, Martin v. Löwis wrote: >>> So specifying 2.5 would be a short-hand for *what*? >> >> 2.5 would be a shorthand for 2.5.x. So, equivalent to : >=2.5.0, < 2.6.0 > > Ok, so it's not a shorthand for a single operator anymore, but for a > more complex term. Fine with me. > >> 2.5.0 would be the notation required to describe this specific micro version. > > I think it would be a shorthand for >=2.5.0, <2.5.1, right? Actually, the logical extension is that 2.5.0 is shorthand for >=2.5.0.0, <2.5.1.0, I believe. PEP 386 versions can have an indefinite number of extradecimal versions. Pedantically, -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, Dec 28, 2009 at 12:02, Tarek Ziadé 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, Dec 28, 2009 at 12:04 PM, Lennart Regebro wrote: > On Mon, Dec 28, 2009 at 12:02, Tarek Ziadé wrote: >> -1. This looks like typos the developer made on his versions definitions. > > Nah. > >> And if not, is subject to errors by forgetting dashes or dots. > > Eh, yeah but that goes for ANY syntax. > > Having the same syntax as for package specifications does make sense, though. > (So we should clearly change that one too, eh?) I don't think we need to change the syntax in fact. The current one, with simple operators covers the needs as far as I see. What was fuzzy is the meaning of version strings like "2.5". Once it's clarified (and it seems we have a better definition already since a few mails), I think the current syntax works naturally with ranges. Regards Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, Dec 28, 2009 at 12:02 PM, Lennart Regebro wrote: > On Mon, Dec 28, 2009 at 11:54, "Martin v. Löwis" wrote: >> This == operator is fairly common in Debian. For example, the apache2 >> package installed on my system specifies > > Oh, absolutely, but that's when you specify interdependencies between > packages. Nobody makes a Python package for generic use and say "you > should only use this with Python 2.5.0 and nothing else". > Specifying > zope.interfaces 1.2.3 for zope.component 1.2.3 makes a lot of sense, > but specifying only Python 2.5.0? It's quite improbable but it could technically happen. For example, let's say I create a third-party project that provides a specific workaround for a bug that was founded in Python 2.5.0 but fixed in Python 2.5.1. IOW defining how versions work should be a set of explicit rules that shouldn't rely on assumptions made on their usage in some specific projects, but rather provides something that covers all needs. Regards, Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
Lennart Regebro writes: > On Mon, Dec 28, 2009 at 11:54, "Martin v. Löwis" wrote: > > This == operator is fairly common in Debian. For example, the > > apache2 package installed on my system specifies > > Oh, absolutely, but that's when you specify interdependencies between > packages. Nobody makes a Python package for generic use and say "you > should only use this with Python 2.5.0 and nothing else". Specifying > zope.interfaces 1.2.3 for zope.component 1.2.3 makes a lot of sense, > but specifying only Python 2.5.0? I'm operating from the principle that there should not be a special syntax that only applies to dependency on the version of Python. The same syntax used for specifying any dependency on any package should also be sufficient for specifying a dependency on Python itself. That being so, the cost in complexity of having a special dependency syntax just for the version of Python should weigh strongly against introducing one. -- \ “First things first, but not necessarily in that order.” —The | `\ Doctor, _Doctor Who_ | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
> > How can they know that they depend on "a quirk in behaviour of an older > > version" if a newer version hasn't been released? This sounds bogus. > > Of course a newer version has been released. Who said it hasn't been? > Eg, the discussion of <=2.5. Hasn't 2.6 been released? Or am I > hallucinating? So, what you are saying is that software X specifies that it is compatible with "2.5 or later" as long as 2.6 hasn't been released, but when 2.6 is released it switches to "2.5 but not 2.6"? > The point is that some packages depend on >=2.5, and others depend on > <=2.5. I see no reason to deprecate the "<=" notation. That's not really what we are talking IIUC. We are talking about behaviour of "2.5" vs. "2.5.0". ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
Antoine Pitrou writes: > > > > How can they know that they depend on "a quirk in behaviour of an older > > > version" if a newer version hasn't been released? This sounds bogus. > > > > Of course a newer version has been released. Who said it hasn't been? > > Eg, the discussion of <=2.5. Hasn't 2.6 been released? Or am I > > hallucinating? > > So, what you are saying is that software X specifies that it is > compatible with "2.5 or later" as long as 2.6 hasn't been released, but > when 2.6 is released it switches to "2.5 but not 2.6"? No, I'm not. Let's drop it, as Tarek seems disposed to dismiss the bikeshedding (including this subthread) anyway, which is TheRightThing. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
2009/12/28 "Martin v. Löwis" : > >> Does that mean we should add "or"? >> >> Requires-Python: 2.5 or 2.6 > > It would be redundant to have it, since you can also write > > Requires-Python: >=2.5, <2.7 > >> Should we also use "and" instead of ","? >> >> Requires-Python: >= 2.5 and < 2.6 > > Perhaps. I think the Linux packaging formats uniformly use the comma. (I'm picking a somewhat random message to reply to here - in general, I agree with the sentiments expressed in Martin's mail). It seems to me that there's too much of an attempt to invent "do what I mean" semantics, which is complicating the whole issue here. Python prefers "explicit is better than implicit" over the Perl "do what I mean". I don't see why that should be any less the case here. It seems to me that everything people might want to express can be covered with the existing operators, plus comma meaning "and". Maybe some people find "2.5, 2.6" more obvious than ">= 2.5, < 2.7" - but satisfying them at the cost of introducing complexity and ambiguity into the syntax seems to me to be a serious mistake. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tarek Ziadé wrote: > 2009/12/28 "Martin v. Löwis" : >>> I think Antoine's proposal is good (using the range when "2.5" is >>> used, and using 2.5.0 when explicitely >>> needed), and fixes Martin's concerns. >>> >>> So I would be in favor of removing ~= and using Antoine's rule; >> So specifying 2.5 would be a short-hand for *what*? > > 2.5 would be a shorthand for 2.5.x. So, equivalent to : >=2.5.0, < 2.6.0 > > 2.5.0 would be the notation required to describe this specific micro version. > > For third-party projects, the same rule would apply. > > The only particular point is about projects that don't use the .0 > micro notation for the first version of a series. > In that case, "2.5" will still mean ">=2.5, < 2.6.0" > > IOW, if someone needs a full MAJOR.MINOR.MICRO comparison, he will > have to explicitely > tell if by providing a detailed version, even if he needs to fill it > with some ".0"s > > This will of course be applicable only for PEP 386-compatible > versions. So for "Requires-Externals", the > range might not apply (as I stated in the PEP) > > Some examples: > > Requires-Dist: zope.interface (3.1) ==> any versions that starts > with 3.1, not including post- or pre- releases > Requires-Dist: zope.interface (3.1.0) ==> only 3.1.0 For completeness, isn't this really "any versino which starts with 3.1.0, not including post- or pre- releases"? That particular pacakge doesn't use more than a third version component, but there are packages in the wild which use four. > Requires-Python: 3 ==> Python 3 (no > matter wich one) > Requires-Python: >=2.6,<3 ==> Any version of Python > 2.6.x or 2.7.x (and 2.8.x if it exists one day) > Requires-Python: 2.6.2 ==> only Python 2.6.2 Here, the issue is only theoretical: Python dosn't issue "fourth dot" releases. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@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- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, 28 Dec 2009 10:42:20 +0100, "Martin v. Löwis" wrote: > On distutils-sig, a vocal fraction seems to think otherwise. From my > short interaction there, I now think that comparison operators are > indeed hard to use, and that the concept of a half-open interval, > and how you can use relational operators involving the endpoints > to denote it, is (apparently) *quite* advanced. Absolutely. From Len and my interactions, I will wrap up and make one addition to the set. I'm adding one last proposition. > Requires-Python: 3 Requires a particular python version. > Requires-Python: 2.5:2.7 Specifies a range of python versions. > Requires-Python: 2.4+ Specifies anything above a particular python version. (No need to ask me about a less than operator. I think a packager would feel more comfortable with using the range operator than a 'less-than' operator. There just comes a point where people don't bother with old interpreter versions) That wraps it up for the vocal faction... Happy new year David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On 28/12/2009 22:57, David Lyon wrote: On Mon, 28 Dec 2009 10:42:20 +0100, "Martin v. Löwis" wrote: On distutils-sig, a vocal fraction seems to think otherwise. From my short interaction there, I now think that comparison operators are indeed hard to use, and that the concept of a half-open interval, and how you can use relational operators involving the endpoints to denote it, is (apparently) *quite* advanced. Absolutely. > From Len and my interactions, I will wrap up and make one addition to the set. I'm adding one last proposition. > Requires-Python: 3 Requires a particular python version. > Requires-Python: 2.5:2.7 Specifies a range of python versions. So this would work for Python 2.7 but *not* 2.7.1? Or does 2.7 implicitly mean a range of all Python 2.7 versions? If not how do we specify up to the last version of 2.6 (which may not yet be released) but *not* 2.7? 2.5:2.6.9 ? Michael > Requires-Python: 2.4+ Specifies anything above a particular python version. (No need to ask me about a less than operator. I think a packager would feel more comfortable with using the range operator than a 'less-than' operator. There just comes a point where people don't bother with old interpreter versions) That wraps it up for the vocal faction... Happy new year David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, 28 Dec 2009 23:07:32 +, Michael Foord wrote: >>> Requires-Python: 2.5:2.7 >> >> Specifies a range of python versions. >> > So this would work for Python 2.7 but *not* 2.7.1? Or does 2.7 > implicitly mean a range of all Python 2.7 versions? Yes. 2.7 would mean all 2.7 versions. As 2.7.1 is a 2.7 release. > If not how do we specify up to the last version of 2.6 (which may not > yet be released) but *not* 2.7? > > 2.5:2.6.9 ? No. As you might never know what the last release may ever be as they keep on coming. So like this: > Requires-Python: 2.5:2.6 That will catch all 2.6 unreleased versions (security fixes et la) and not 2.7 David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
David Lyon 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
Antoine Pitrou wrote: David Lyon preisshare.net> writes: Requires a particular python version. > Requires-Python: 2.5:2.7 Why not drop ranges as well as operators and simply use commas? The above would be rewritten as: Requires-Python: 2.5, 2.6, 2.7 This would prevent the ambiguity on the inclusive or exclusive nature of the upper bound of the range. That would mean that commas mean "and" for some entries but "or" for others. You might argue that if you want to include 8 versions of Python this makes the notation slightly longer, but who tests their package with 8 different versions of Python? (and if you don't test exhaustively, just use the "2.5+" notation) Wouldn't "2.5+" include "3"? How often would that be used, considering the differences between Python 2.x and Python 3.x? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, 28 Dec 2009 23:21:54 +, Antoine Pitrou wrote: > David Lyon preisshare.net> writes: > > > > Requires a particular python version. > > > > > Requires-Python: 2.5:2.7 > > Why not drop ranges as well as operators and simply use commas? > The above would be rewritten as: > > Requires-Python: 2.5, 2.6, 2.7 > > This would prevent the ambiguity on the inclusive or exclusive nature of the > upper bound of the range. What about specifying that the package works only with, say, 2.6.2 or earlier (because of some problem introduced by 2.6.3)? That could get pretty darn verbose. (Also remember we aren't just talking about the syntax for Python versions, but versions for any package). I do think it is also a valid argument that, from what I've heard here, most extant (linux at least) packaging systems use the >=, etc, operators, so I think talking about changing the proposed syntax radically is probably misplaced. -- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
R. David Murray bitdance.com> writes: > > > Why not drop ranges as well as operators and simply use commas? > > The above would be rewritten as: > > > > Requires-Python: 2.5, 2.6, 2.7 > > > > This would prevent the ambiguity on the inclusive or exclusive nature of the > > upper bound of the range. > > What about specifying that the package works only with, say, 2.6.2 or > earlier (because of some problem introduced by 2.6.3)? That could get > pretty darn verbose. (Also remember we aren't just talking about the > syntax for Python versions, but versions for any package). Ok, you're right. Let's drop my proposal then. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, 28 Dec 2009 23:21:54 + (UTC), Antoine Pitrou wrote: >> > Requires-Python: 2.5:2.7 > > Why not drop ranges as well as operators and simply use commas? > The above would be rewritten as: > > Requires-Python: 2.5, 2.6, 2.7 Firstly, I find your notation proposition to be entirely workable and rational. Len threw in the range notation as a kind of novel idea, but the more I use it, the more that I think it is applicable in this use case. Packages and the interpretor version is about ranges. The choice (for the packager) comes down to either one particular python version (2, 2.x, or 3, or 3.x), or a range of python versions, or a set. There's no reason that I can see why we could not have both, that is a set and a range as Len has suggested. Whether the delineation is with commas or spaces is, to me, is minor. > You might argue that if you want to include 8 versions > of Python this makes the notation slightly longer, but > who tests their package with 8 different versions > of Python? You're right. The set notation is more obtuse. But with your notation, I hope there would be no problem. For instance: > Requires-Python: 2, 3 To me that would cover all 8 versions. As for the testing thing, well that's the cpan debate.. another thread. > (and if you don't test exhaustively, just use the "2.5+" notation) Exactly. David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, 28 Dec 2009 18:55:17 -0500, "R. David Murray" wrote: > What about specifying that the package works only with, say, 2.6.2 or > earlier (because of some problem introduced by 2.6.3)? That could get > pretty darn verbose. (Also remember we aren't just talking about the > syntax for Python versions, but versions for any package). That's why the range operator could be good. > Requires-python: 2.4:2.6.2 > I do think it is also a valid argument that, from what I've heard here, > most extant (linux at least) packaging systems use the >=, etc, operators, > so I think talking about changing the proposed syntax radically is > probably misplaced. The counter argument for 'cloning' the linux packaging system is that most of the representations come from a C perspective. Because of the fact that Linux is predominantly a C product. Since Python isn't C, and doesn't come from C, then one could argue that using short-hand or high level notation is more in keeping with the character of python. So the arguments against the >= == operators come from the desire to keep what looks like C code, *out-of* python packaging. I fully sympathise that some have the desire simply to clone what's already out there. Why make new art when there's a lot of old art already.. The price of doing that is we lose the specific short-handed high-level nature of python. Which is what we were attracted to in the first place. David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
David Lyon writes: > The counter argument for 'cloning' the linux packaging system is that > most of the representations come from a C perspective. Because of the > fact that Linux is predominantly a C product. > > Since Python isn't C, and doesn't come from C, then one could argue > that using short-hand or high level notation is more in keeping with > the character of python. Even if that were true (and it's not at all clear that “Python does not come from C”), that's a classic “not invented here” (NIH) argument. NIH is widely regarded as a very poor reason to reject something that works. The dependency declarations are *not* Python language syntax, and there is no need to consider Python language syntax in defining them. -- \ “When we talk to God, we're praying. When God talks to us, | `\ we're schizophrenic.” —Jane Wagner, via Lily Tomlin, 1985 | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Mon, Dec 28, 2009 at 9:26 PM, Tres Seaver wrote: [..] >> Requires-Dist: zope.interface (3.1.0) ==> only 3.1.0 > > For completeness, isn't this really "any versino which starts with > 3.1.0, not including post- or pre- releases"? That particular pacakge > doesn't use more than a third version component, but there are packages > in the wild which use four. [..] >> Requires-Python: 2.6.2 ==> only Python 2.6.2 > > Here, the issue is only theoretical: Python dosn't issue "fourth dot" > releases. Both points are right. I'll remove from the PEP the range operator and provide a definition for 2.5 vs 2.5.x vs 2.5.0, as well as all these examples, corrected. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
David Lyon wrote: On Mon, 28 Dec 2009 23:07:32 +, Michael Foord wrote: > Requires-Python: 2.5:2.7 Specifies a range of python versions. So this would work for Python 2.7 but *not* 2.7.1? Or does 2.7 implicitly mean a range of all Python 2.7 versions? Yes. 2.7 would mean all 2.7 versions. As 2.7.1 is a 2.7 release. I suggest that this follow the Python syntax for ranges, where the end is non-inclusive. So "2.5:2.7" would mean "greater than or equal to 2.5, and less than 2.7". Which suggests that "2.5:" could be equivalent to "2.5+", as well as allowing ":3" to mean "any version less than 3.0". Cheers, /larry/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Tue, Dec 29, 2009 at 2:17 AM, sstein...@gmail.com wrote: > > On Dec 28, 2009, at 8:00 PM, Ben Finney wrote: > >> The dependency declarations are *not* Python language syntax, and there >> is no need to consider Python language syntax in defining them. > > Agreed. > > We're also not going to be writing an operating system with them; just simple > version range statement. > > I think that the range expression: > > 2.5:2.7 > > is easy to read, immediately understandable, and expresses everything that > needs to be said. > > Yes, it needs to be stated that the ends are inclusive, but after that, it's > pretty obvious what it means at a glance The syntax as it is already defined in the PEP can be used to define what we need. The part that was unclear was about the meaning of "2.5". e.g.: 2.5.0 or 2.5.x.. It became obvious in the thread that it means 2.5.x. (e.g. a range) so there's no need to introduce any range operator, wether it's "~=" or a new notation with ":". IOW, since the syntax already present in the PEP is sufficient for our needs (besides ~=) , and as long as the precise definition of "version string" is provided, I consider that further discussion about the syntax itself is more or less bikeshedding. I am now rewriting the relevant section of the PEP with the examples we discussed in this thread, but the operators should stay the same as they were initially: "<", ">", "<=", ">=", "==" and "!=". Regards Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Dec 28, 2009, at 8:35 PM, Tarek Ziadé wrote: > On Tue, Dec 29, 2009 at 2:17 AM, sstein...@gmail.com > wrote: >> >> On Dec 28, 2009, at 8:00 PM, Ben Finney wrote: >> >>> The dependency declarations are *not* Python language syntax, and there >>> is no need to consider Python language syntax in defining them. >> >> Agreed. >> >> We're also not going to be writing an operating system with them; just >> simple version range statement. >> >> I think that the range expression: >> >>2.5:2.7 >> >> is easy to read, immediately understandable, and expresses everything that >> needs to be said. >> >> Yes, it needs to be stated that the ends are inclusive, but after that, it's >> pretty obvious what it means at a glance > > The syntax as it is already defined in the PEP can be used to define > what we need. The part that was unclear was about the meaning of > "2.5". e.g.: 2.5.0 or 2.5.x.. > > It became obvious in the thread that it means 2.5.x. (e.g. a range) so > there's no need to introduce any range operator, wether it's "~=" or a > new notation with ":". > > IOW, since the syntax already present in the PEP is sufficient for our > needs (besides ~=) , and as long as the precise definition of "version > string" is provided, I consider that further discussion about the > syntax itself is more or less bikeshedding. > > I am now rewriting the relevant section of the PEP with the examples > we discussed in this thread, but the operators should stay the same as > they were initially: "<", ">", "<=", ">=", "==" and "!=". Fine by me. My original contention was that we should be referencing that document as it already defined everything we needed and that any syntactic sugar be defined in those terms. The ":" syntactic sugar appeals to me but is, as you say, not necessary. S ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
Tarek Ziadé writes: > I am now rewriting the relevant section of the PEP with the examples > we discussed in this thread, but the operators should stay the same as > they were initially: "<", ">", "<=", ">=", "==" and "!=". Thank you, this is the clear and simple path and keeps the dependency declarations in line with existing conventions. -- \ “Let others praise ancient times; I am glad I was born in | `\ these.” —Ovid (43 BCE–18 CE) | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Tue, 29 Dec 2009 12:00:50 +1100, Ben Finney 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
