Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
Hi Martin, Happy New Year, >>> Requires-Dist: pywin32 (>1.0); sys.platform == 'win32' >> >> Requires-Dist: [Windows] pywin32 1.0+ >> >> That's simpler, shorter, and less ambiguous. Easier to >> parse for package managers. > > Don't you want the PEP to complete? Why this bike-shedding? Well, I'm just helping out by pointing out some simpler ways as Tarek asked me. I was only answering his question. I was out celebrating so it took longer to reply than normal. Bike-Shedding ? Me ? which bikeshed? wanting simple? Anyway, I'm just reading the PEPs and commenting. If there are some alterations that can be done, lets discuss them. > I can agree it's shorter. > .. Cool. What I'd really like is a 'Code-Repository:' keyword so that we can install programs/libraries directly into a system. I feel that this would really simplify the packaging landscape, making it much easier for the scientific community and others to do python software installs. This would allow us to perphaps have something even *more modern* than CPAN. So yes, getting PEP-345 right is important to me. Have a nice day. David ___ 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 Jan 3, 2010, at 7:21 PM, Martin v. Löwis wrote: >>> Requires-Dist: pywin32 (>1.0); sys.platform == 'win32' >> >> Requires-Dist: [Windows] pywin32 1.0+ >> >> That's simpler, shorter, and less ambiguous. Easier to >> parse for package managers. > > Don't you want the PEP to complete? Why this bike-shedding? Really Enough, already! S ___ 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
>> Requires-Dist: pywin32 (>1.0); sys.platform == 'win32' > > Requires-Dist: [Windows] pywin32 1.0+ > > That's simpler, shorter, and less ambiguous. Easier to > parse for package managers. Don't you want the PEP to complete? Why this bike-shedding? I can agree it's shorter. I can't agree that it's simpler, or less ambiguous. Regards, Martin ___ 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, Dec 28, 2009 at 1:15 AM, Tarek Ziade wrote: This new operator removes the ambiguity the original proposal had, without making it more complex for common use cases. So if you dislike it, you will need to propose something else that also fixes the ambiguity we had. Ok. Environment markers .. Here are some example of fields using such markers: Requires-Dist: pywin32 (>1.0); sys.platform == 'win32' Requires-Dist: [Windows] pywin32 1.0+ That's simpler, shorter, and less ambiguous. Easier to parse for package managers. 'win32' is more specific than 'Windows' and, to me, '1.0+' means '>=1.0', not '>1.0'. ___ 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 1:15 AM, Tarek Ziade wrote: > > This new operator removes the ambiguity the original proposal had, > without making it more > complex for common use cases. So if you dislike it, you will need to > propose something > else that also fixes the ambiguity we had. Ok. > Environment markers >.. >Here are some example of fields using such markers: > >Requires-Dist: pywin32 (>1.0); sys.platform == 'win32' Requires-Dist: [Windows] pywin32 1.0+ That's simpler, shorter, and less ambiguous. Easier to parse for package managers. David ___ 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
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 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
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
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 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
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
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, 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
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
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 +, 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
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
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
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
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 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
-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
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
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
> > 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
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
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
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, 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 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 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 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
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: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
> 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
>> 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
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
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
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
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
> 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
> 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
> 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
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
> 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
> 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
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
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
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
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
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
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 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 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
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
> david.l...@preisshare.net writes: > > > With respect, it's not a very common use case for a developer to > > say that package needs a python interpretor 'older' than 2.5. > > Of course it is. I don't claim it is the majority of cases out there, > but stable versions of many of the packages I use will specify an > older python (Mailman and Zope both specify a range of Pythons, rarely > including the most recent release, and Bazaar, although it tries to > keep up with Python releases, tends to recommend being conservative, > sticking to release (n-1) for the first few months into release n.) > > And in fact this case is often more the important one. Packages that > depend on having a *recent* version of python will often crash > quickly, before doing permanent damage, when an undefined syntax, > function, or method is invoked, while packages that depend on a quirk > in behavior of an older version will typically silently corrupt data. > > > imho, all that they would know, is that they're using python > > (for example) 2.4 or 2.5 (pick a python version) and they > > know it works pretty well. > > If they want to specify a Python version that works, they may as well > bundle it, and many do. But even in that case the user may want to > know about the dependency. > > BTW, *all* of the Python applications I really care about make a point > of specifying a range of versions they work with (or bundle a > particular version). So in fact many developers do know what versions > work or fail, and often why (and they sometimes even provide > workarounds/patches for adventurers who want to use a Python outside > of the recommended range). > > > It's then up to the user if they want to use it on any other > > version. > > This is often an undesirable posture. From the user's point of view, > the system version of Python may have passed various local tests and > therefore be strongly preferred (for example, requiring far less time > for approval from the security team). This is especially true for > mail or web applications and other applications that must run in a > very hostile environment. Many developers do want to provide this > kind of information to such users. > > I think you should rethink your position on how valid your personal > intuitions are for generalization. You are certainly representative > of a certain important segment of developers, but I don't think you > have a good sense of the very broad class of requirements that other > developers are bringing to the table. > ___ 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 in fact this case is often more the important one. Packages that > depend on having a *recent* version of python will often crash > quickly, before doing permanent damage, when an undefined syntax, > function, or method is invoked, while packages that depend on a quirk > in behavior of an older version will typically silently corrupt data. How can they know that they depend on "a quirk in behaviour of an older version" if a newer version hasn't been released? This sounds bogus. Besides, not letting me install their app/library on a newer Python just because they are not /sure/ it will work is IMO an active nuisance. The user should be treated as an adult. ___ 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 writes: > With respect, it's not a very common use case for a developer to > say that package needs a python interpretor 'older' than 2.5. Of course it is. I don't claim it is the majority of cases out there, but stable versions of many of the packages I use will specify an older python (Mailman and Zope both specify a range of Pythons, rarely including the most recent release, and Bazaar, although it tries to keep up with Python releases, tends to recommend being conservative, sticking to release (n-1) for the first few months into release n.) And in fact this case is often more the important one. Packages that depend on having a *recent* version of python will often crash quickly, before doing permanent damage, when an undefined syntax, function, or method is invoked, while packages that depend on a quirk in behavior of an older version will typically silently corrupt data. > imho, all that they would know, is that they're using python > (for example) 2.4 or 2.5 (pick a python version) and they > know it works pretty well. If they want to specify a Python version that works, they may as well bundle it, and many do. But even in that case the user may want to know about the dependency. BTW, *all* of the Python applications I really care about make a point of specifying a range of versions they work with (or bundle a particular version). So in fact many developers do know what versions work or fail, and often why (and they sometimes even provide workarounds/patches for adventurers who want to use a Python outside of the recommended range). > It's then up to the user if they want to use it on any other > version. This is often an undesirable posture. From the user's point of view, the system version of Python may have passed various local tests and therefore be strongly preferred (for example, requiring far less time for approval from the security team). This is especially true for mail or web applications and other applications that must run in a very hostile environment. Many developers do want to provide this kind of information to such users. I think you should rethink your position on how valid your personal intuitions are for generalization. You are certainly representative of a certain important segment of developers, but I don't think you have a good sense of the very broad class of requirements that other developers are bringing to the table. ___ 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 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.
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.
___
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: > 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. 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 iEYEARECAAYFAks4QAwACgkQ+gerLs4ltQ5LJACfY9ijtkw/Bsyg2xXp93xNtbhy QAUAnRBZWSMk+izGDEjVkHVLpu418gfR =vM/V -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
david.l...@preisshare.net writes: > >> Before we had : Requires-Python: 2.5, 2.6 > >> > >> That made much more sense. It was simple and unambiguous, and is > >> relevant to typical packaging scenarios. > > > > Unfortunately, it is fairly ambiguous, and makes no sense. It means > > "requires Python 2.5 *AND* requires Python 2.6", which is a requirement > > that no single version can meet. > > No, it means a library requires either python 2.5 *OR* python 2.6 to be > installed properly. If Martin and the SIG disagree on the interpretation (and I see Martin's point: in ">=2.5, <2.6" the comma is a conjunction, not a disjunction), that's too much ambiguity for me. -1 ___ 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 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. 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 iEYEARECAAYFAks4PzUACgkQ+gerLs4ltQ551gCgyVNvpJayTWGiCNbg4NKw4p/y uG8An1u90cHfKVaUqIAkUlZSI92g6PxL =7h2c -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
>> Tarek Ziadé gmail.com> writes: > An implicit range operator is simpler indeed, and achieves the same goal. > > Meaning that "<=2.5" for example, will be translated to "<=2.5.x" as well. With respect, it's not a very common use case for a developer to say that package needs a python interpretor 'older' than 2.5. There comes a point where you can just not expect a python interpretor, say 1.3, to not work with your package. So they wouldn't say that. I don't think. Nor would they say it going forward. So ">=2.5" might be too bold a claim for them to make. As they might not have tested on the 'latest-and-greatest' interpretor. That would imply that they know it works on all 3 series interpretors. imho, all that they would know, is that they're using python (for example) 2.4 or 2.5 (pick a python version) and they know it works pretty well. It's then up to the user if they want to use it on any other version. That's why I don't think we need the '=' '>=' operator characters to represent typical use cases. If there's any use-case, that I have missed. Do let me know. David ___ 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/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 "~=" operator looks murkier than it needs to be IMO. Agreed, though not likely to affect me too much. Terry Jan Reedy ___ 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
> Instead, the default should be â==â. That is, âRequires-Python: 3â > should be equivalent to âRequires-Python: ==3â; and only â3â or > â3.0â or > â3.0.0â etc. will match. I maintain that is what most people will > expect > on seeing that syntax. > > If a less strict range is desired, the existing comparison operators > â>â, â>=â, â<â, â<=â are sufficient, more obvious, and > more explicit. In > other words, to get the meaning you desire above, the existing operators > can be used: âRequires-Python: >=3, <4â. Yes, so that: Requires-Python: 1,2,3 means python versions 1,2 or 3. Requires-Python: 3 means requires python 3 only. Any version of 3 Whereas: Requires-Python: 3.0, 3.1 means only 3.0 and 3.1 Requires-Python: 2.3, 2.4, 2.5, 2.6 That means, those particular versions. A user can still try to install on other versions. But they would get a warning and would do so at their own risk. There's no need for extra operator characters as far as I can see. The comma method proposed originally seemed to do everything. David ___ 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
>> No application developer will quickly figure out what a tilde means. >> Maybe >> it means 'roughly', but it requires too much thought and is ambiguous. >> 2.5 >> is not roughly 2.5.2. It is the same exactly. >> >> Before we had : Requires-Python: 2.5, 2.6 >> >> That made much more sense. It was simple and unambiguous, and is >> relevant >> to typical packaging scenarios. > > Unfortunately, it is fairly ambiguous, and makes no sense. It means > "requires Python 2.5 *AND* requires Python 2.6", which is a requirement > that no single version can meet. No, it means a library requires either python 2.5 *OR* python 2.6 to be installed properly. If not, the implication is that the user will be prompted to install anyway. David ___ 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
Ben Finney writes: > Instead, the default should be `=='. That is, `Requires-Python: 3' > should be equivalent to `Requires-Python: ==3'; and only "3" or "3.0" or > "3.0.0" etc. will match. I maintain that is what most people will expect > on seeing that syntax. I really don't think your assessment that a majority agrees with you is warranted. The demand for backward compatibility is so strong that (wearing my maintainer hat, in other projects) I actually assume that in compatibility claims a bare version number like 3 means >= 3.0.0 to my listeners, unless explicitly qualified. Therefore, I think there should be no default. "Explicit is better than implicit." And IMO the choice of "~=" or "=~" for the range match should be avoided, since that looks like the regexp search operator in Perl, and there "~= 3" would match "3", "3.0.4", and "2.3.5". The next obvious interpretation is "fuzzy match", but that doesn't have an obvious, more specific meaning. The usual comparson operators do have pretty obvious interpretations, and are not hard to use. ___ 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
Arfrever Frehtes Taifersar Arahesis wrote: 2009-12-28 02:17:22 Ben Finney napisał(a): Tarek Ziadé writes: On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar wrote: Also, "Requires-Python: 3" would include all 3.X versions, correct? Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= 3" which is equivalent to "Requires-Python: 3.x.x" This is totally counter to conventional comparisons, and is an excellent example of why the equivalence of ‘3’ to ‘>=3, <4’ is a bad idea. Instead, the default should be ‘==’. That is, ‘Requires-Python: 3’ should be equivalent to ‘Requires-Python: ==3’; and only “3” or “3.0” or “3.0.0” etc. will match. I maintain that is what most people will expect on seeing that syntax. If a less strict range is desired, the existing comparison operators ‘>’, ‘>=’, ‘<’, ‘<=’ are sufficient, more obvious, and more explicit. In other words, to get the meaning you desire above, the existing operators can be used: ‘Requires-Python: >=3, <4’. IMHO 'Requires-Python: 3*' (or '3.*') would be better than 'Requires-Python: >=3, <4'. '3.*' would be the better of the two. ___ 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
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 ___ 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/27/2009 5:21 PM, MRAB wrote: 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" To me it's non-intuitive that "<=2.5" means <=2.5.0 but "2.5" means 2.5.x; it's not consistent, explicit is better than implicit, etc. Yes. When we talk about Python-2.5 (as in, for instance, "this script requires Python 2.5 to run"), we are referring to 2.5.x, and not just 2.5.0. I'd prefer it if omission means "don't care", so "2" means 2.x.y and "2.5" means 2.5.x. +1. On 12/27/2009 4:37 PM, Tarek Ziadé wrote: > As discussed in Distutils-SIG, 2.5 is not strictly equal to 2.5.2. > That's exactly why we introduced > the range operator. So one may make a clear distinction between > "2.5.x" and "2.5". Perhaps if "2.5" was instead considered to be a *range* of possible versions (2.5.0, ... 2.5.4), then this ambiguity wouldn't have arisen in first place? Technically (Include/patchlevel.h), it is "2.5.0", not "2.5". -srid ___ 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 27, 2009, at 8:02 PM, Tarek Ziadé wrote: > On Mon, Dec 28, 2009 at 1:48 AM, 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) >> >> This "~=" operator looks murkier than it needs to be IMO. > > An implicit range operator is simpler indeed, and achieves the same goal. > > Meaning that "<=2.5" for example, will be translated to "<=2.5.x" as well. It seems to me that all this version range talk relates pretty directly to PEP 386. The Python version numbers themselves are the simplest type of "Normalized Version"s, and since comparisons of "NormalizedVersion"s are defined in PEP 386, and that's really all we're talking about here, shouldn't this really just follow and reference that document? Sure we might like some sugar to make expressing ranges simpler, but shouldn't the explicit meanings of any rules be stated in terms of Normalized Version comparisons? S ___ 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 Sun, Dec 27, 2009 at 8:28 PM, Arfrever Frehtes Taifersar Arahesis 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. "Chaos is the score upon which reality is written." --Henry Miller ___ 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
Ben Finney wrote: Tarek Ziadé writes: On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar wrote: Also, "Requires-Python: 3" would include all 3.X versions, correct? Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= 3" which is equivalent to "Requires-Python: 3.x.x" This is totally counter to conventional comparisons, and is an excellent example of why the equivalence of ‘3’ to ‘>=3, <4’ is a bad idea. Instead, the default should be ‘==’. That is, ‘Requires-Python: 3’ should be equivalent to ‘Requires-Python: ==3’; and only “3” or “3.0” or “3.0.0” etc. will match. I maintain that is what most people will expect on seeing that syntax. If a less strict range is desired, the existing comparison operators ‘>’, ‘>=’, ‘<’, ‘<=’ are sufficient, more obvious, and more explicit. In other words, to get the meaning you desire above, the existing operators can be used: ‘Requires-Python: >=3, <4’. Perhaps there should be a new range operator: Requires-Python: 3 ~ 4 Half-open, of course. ___ 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 02:17:22 Ben Finney napisał(a): > Tarek Ziadé writes: > > > On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar > > wrote: > > > Also, "Requires-Python: 3" would include all 3.X versions, correct? > > > > Correct, because, "Requires-Python: 3" is equivalent to > > "Requires-Python: ~= 3" which is equivalent to "Requires-Python: > > 3.x.x" > > This is totally counter to conventional comparisons, and is an excellent > example of why the equivalence of ‘3’ to ‘>=3, <4’ is a bad idea. > > Instead, the default should be ‘==’. That is, ‘Requires-Python: 3’ > should be equivalent to ‘Requires-Python: ==3’; and only “3” or “3.0” or > “3.0.0” etc. will match. I maintain that is what most people will expect > on seeing that syntax. > > If a less strict range is desired, the existing comparison operators > ‘>’, ‘>=’, ‘<’, ‘<=’ are sufficient, more obvious, and more explicit. In > other words, to get the meaning you desire above, the existing operators > can be used: ‘Requires-Python: >=3, <4’. IMHO 'Requires-Python: 3*' (or '3.*') would be better than 'Requires-Python: >=3, <4'. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ 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é 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" 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. ___ 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: > On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar > wrote: > > Also, "Requires-Python: 3" would include all 3.X versions, correct? > > Correct, because, "Requires-Python: 3" is equivalent to > "Requires-Python: ~= 3" which is equivalent to "Requires-Python: > 3.x.x" This is totally counter to conventional comparisons, and is an excellent example of why the equivalence of ‘3’ to ‘>=3, <4’ is a bad idea. Instead, the default should be ‘==’. That is, ‘Requires-Python: 3’ should be equivalent to ‘Requires-Python: ==3’; and only “3” or “3.0” or “3.0.0” etc. will match. I maintain that is what most people will expect on seeing that syntax. If a less strict range is desired, the existing comparison operators ‘>’, ‘>=’, ‘<’, ‘<=’ are sufficient, more obvious, and more explicit. In other words, to get the meaning you desire above, the existing operators can be used: ‘Requires-Python: >=3, <4’. -- \ “Not using Microsoft products is like being a non-smoker 40 or | `\ 50 years ago: You can choose not to smoke, yourself, but it's | _o__) hard to avoid second-hand smoke.” —Michael Tiemann | Ben Finney ___ 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é wrote: > On Mon, Dec 28, 2009 at 1:48 AM, 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) >> >> This "~=" operator looks murkier than it needs to be IMO. > > An implicit range operator is simpler indeed, and achieves the same goal. > > Meaning that "<=2.5" for example, will be translated to "<=2.5.x" as well. So that "2.5.4<=2.5", "2.5<=2.5.2", but not "2.5.4<=2.5.2" (i.e. A<=B, B<=C, but not A<=C)? I find that strange. Regards, Martin ___ 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: > FYI we have introduced a range operator, so one may define a range of > versions. This is useful for instance to write: > > Requires-Python: ~=2.5 > > Which means: requires any version of Python 2.5.x. -1 on that syntax. It's an extra operator, with a non-obvious meaning; the meaning should be as clear as feasible even to those who have not read the specification. The existing operators ‘>’, ‘>=’, ‘<’ ‘<=’ are standard and more obvious. That is, the existing operators: Requires-Python: >=2.5, <2.6 explicitly specify the range in your example. -- \ “Value your freedom or you will lose it, teaches history. | `\ “Don't bother us with politics,” respond those who don't want | _o__) to learn.” —Richard Stallman, 2002 | Ben Finney ___ 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 1:48 AM, 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) > > This "~=" operator looks murkier than it needs to be IMO. An implicit range operator is simpler indeed, and achieves the same goal. Meaning that "<=2.5" for example, will be translated to "<=2.5.x" as well. Regards, Tarek ___ 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
> No application developer will quickly figure out what a tilde means. Maybe > it means 'roughly', but it requires too much thought and is ambiguous. 2.5 > is not roughly 2.5.2. It is the same exactly. > > Before we had : Requires-Python: 2.5, 2.6 > > That made much more sense. It was simple and unambiguous, and is relevant > to typical packaging scenarios. Unfortunately, it is fairly ambiguous, and makes no sense. It means "requires Python 2.5 *AND* requires Python 2.6", which is a requirement that no single version can meet. Regards, Martin ___ 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 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" > > -srid > -- 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
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) This "~=" operator looks murkier than it needs to be IMO. 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 12/27/2009 4:15 PM, david.l...@preisshare.net wrote: On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan wrote: >> Martin v. Löwis wrote: > FYI we have introduced a range operator, so one may define a range of > versions. > This is useful for instance to write: > > Requires-Python: ~=2.5 > > Which means: requires any version of Python 2.5.x. This operator is > the default operator, > meaning that you can also write: > > Requires-Python: 2.5 I don't like the ~ at all sorry. The ~ operator is thoroughly confusing. No application developer will quickly figure out what a tilde means. Maybe it means 'roughly', but it requires too much thought and is ambiguous. 2.5 is not roughly 2.5.2. It is the same exactly. Tarek, I am a bit confused at the current proposal combined with the newly introduced range operator. Would "Requires-Python: <=2.5" include 2.5.4 or not? Also, "Requires-Python: 3" would include all 3.X versions, correct? -srid ___ 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 1:15 AM, wrote: >> On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan wrote: >>> Martin v. Löwis wrote: >> FYI we have introduced a range operator, so one may define a range of >> versions. >> This is useful for instance to write: >> >> Requires-Python: ~=2.5 >> >> Which means: requires any version of Python 2.5.x. This operator is >> the default operator, >> meaning that you can also write: >> >> Requires-Python: 2.5 > > I don't like the ~ at all sorry. The ~ operator is thoroughly confusing. > > No application developer will quickly figure out what a tilde means. Maybe > it means 'roughly', but it requires too much thought and is ambiguous. 2.5 > is not roughly 2.5.2. It is the same exactly. As discussed in Distutils-SIG, 2.5 is not strictly equal to 2.5.2. That's exactly why we introduced the range operator. So one may make a clear distinction between "2.5.x" and "2.5". Developers will be able to omit the ~= operator, so they can describe a MAJOR or MAJOR.MINOR version and have the whole range included. > > Before we had : Requires-Python: 2.5, 2.6 > > That made much more sense. It was simple and unambiguous, and is relevant > to typical packaging scenarios. This was ambiguous because it was unclear, as MvL stated, if "2.5" was just "2.5.0" or included versions like "2.5.1" or "2.5.2". The "==" operator is now a strict equal operator. In the current proposal, "Requires-Python: 2.5, 2.6" is equivalent to "Requires-Python: ~=2.5, ~=2.6", which means "Requires Python 2.5.x or Python 2.6.x". So I guess the meaning you were putting behind "Requires-Python: 2.5, 2.6" remains unchanged. > I hope we can go back to the original proposal. This new operator removes the ambiguity the original proposal had, without making it more complex for common use cases. So if you dislike it, you will need to propose something else that also fixes the ambiguity we had. Regards, Tarek ___ 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 Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan wrote: >> Martin v. Löwis wrote: > FYI we have introduced a range operator, so one may define a range of > versions. > This is useful for instance to write: > > Requires-Python: ~=2.5 > > Which means: requires any version of Python 2.5.x. This operator is > the default operator, > meaning that you can also write: > > Requires-Python: 2.5 I don't like the ~ at all sorry. The ~ operator is thoroughly confusing. No application developer will quickly figure out what a tilde means. Maybe it means 'roughly', but it requires too much thought and is ambiguous. 2.5 is not roughly 2.5.2. It is the same exactly. Before we had : Requires-Python: 2.5, 2.6 That made much more sense. It was simple and unambiguous, and is relevant to typical packaging scenarios. I hope we can go back to the original proposal. :-) David ___ 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 Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan wrote: > Martin v. Löwis wrote: >>> I'll remove it and push it in Distutils documentation, then might just >>> provide a link in the PEP References. >> >> That sounds fine to me. > > That would address my questions as well - someone looking for a guide on > how they should deal with different versions of the metadata on the > production and consumption side can look at how distutils deals with it, > leaving the PEP as a pure spec for the metadata format without distutils > API details mixed in. > > (where it makes sense in explaining the use cases for the different > fields, I'm fine with referencing distutils API details though) I've updated the PEP accordingly, and also made some changes after the discussions we had with Martin on Distutils-SIG on how versions are defined. FYI we have introduced a range operator, so one may define a range of versions. This is useful for instance to write: Requires-Python: ~=2.5 Which means: requires any version of Python 2.5.x. This operator is the default operator, meaning that you can also write: Requires-Python: 2.5 Regards Tarek ___ 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
Martin v. Löwis wrote: >> I'll remove it and push it in Distutils documentation, then might just >> provide a link in the PEP References. > > That sounds fine to me. That would address my questions as well - someone looking for a guide on how they should deal with different versions of the metadata on the production and consumption side can look at how distutils deals with it, leaving the PEP as a pure spec for the metadata format without distutils API details mixed in. (where it makes sense in explaining the use cases for the different fields, I'm fine with referencing distutils API details though) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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'll remove it and push it in Distutils documentation, then might just > provide a link in the PEP References. That sounds fine to me. 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 Thu, Dec 24, 2009 at 10:26 AM, "Martin v. Löwis" wrote: > David Lyon wrote: >> On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull" >> wrote: >> >>> Martin's point is that the PEP process doesn't *have* "reference" >>> implementations. It has *sample* implementations. It may be useful >>> to refer to a sample implementation as an example.. >> >> Fair enough. But otoh, asking for sample implementations on this >> type of project can skew the PEP towards a particular implementation >> or product. > > Nobody is "asking" for sample implementations. Instead, I'm asking that > what Tarek calls a "reference implementation" should be called a > "sample implementation" instead. I'm asking for that precisely to avoid > a skew towards a particular implementation. I'll remove it and push it in Distutils documentation, then might just provide a link in the PEP References. Tarek ___ 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/23 "Martin v. Löwis" : >> So that will happen in the code of course, but we need the PEP to state >> clearly >> wether metadata 1.0 and 1.1 should be dropped by implementations or not. > > Ok. We should recommend that implementations support these versions > indefinitely. I see no point in dropping them. > > But then, this is really up to the implementations. OK, that's fine with me. So I'll remove references to deprecated fields in PEP 345, which will just describes 1.2, and I will also remove the fact that it was marked as the replacer of PEP 314 in the header. [..] >> PyPI doesn't produce PKG-INFO files AFAIK, it just consumes them, no ? > > Correct - but that's also an implementation of the PEP. > >> I am referring to the implementation in Distutils that produces 1.0 >> *or* 1.1 PKG-INFO files. > > But it works both ways. Applications that consume then need to decide > what versions they want to consume. They know it because it is marked in the file in the first line. e.g. a reader has to be able to read all versions. IOW they are not the ones that decide what metadata version a distribution contains. >>> Please do keep distutils out of PEP 345. The remaining occurrences >>> (such as what the "interpret_marker" function does) should be removed. >> >> That's the reference implementation of a PEP 345 reader/writer that >> happens to be in the stdlin. For what reason should we remove it from >> the PEP ? > > Because there shouldn't be a reference implementation. If we have > both a spec and an a reference implementation, then we need to define > what happens in case they conflict. If the reference implementation > is right, implementers of the PEP would *also* need to study the > reference implementation to find out what conforming behaviour is. > > This is bad; the PEP should be the only definition of the metadata > format. Ok, I'll remove that part. Regards Tarek -- Tarek Ziadé | http://ziade.org ___ 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 Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull" > wrote: > >> Martin's point is that the PEP process doesn't *have* "reference" >> implementations. It has *sample* implementations. It may be useful >> to refer to a sample implementation as an example.. > > Fair enough. But otoh, asking for sample implementations on this > type of project can skew the PEP towards a particular implementation > or product. Nobody is "asking" for sample implementations. Instead, I'm asking that what Tarek calls a "reference implementation" should be called a "sample implementation" instead. I'm asking for that precisely to avoid a skew towards a particular implementation. Regards, Martin ___ 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
> As an application developer, I really stand with Tarek here. Not sure what specific point of Tarek you are supporting, though. I think we want something stronger than that since they were not really used by the community and removed and replaced by something better. Using them should raise a warning so developers abandon them, so it would be "don't use 1.1 anymore" > > Yes. But that is a software warning message to be implemented within > the installation software. The important thing is what is in the > metadata. That's my point, not Tarek's, though (the text you quote and that you seem to object to is from Tarek). >> I am just describing the needs and the end user PoV with the reference >> implementation that happens to be used by *all* tools out there. > > That's good. That's what we need right now. Why then bother with describing the data format, when you *really* want people to use the API? Shouldn't you then define the API instead, and leave the format as an implementation detail? I'm fine with having a sample implementation that tools *may* use, but it should be possible to implement the PEP without the sample implementation (and indeed, PyPI may not use that sample implementation, as it has already implemented most of the PEP, to support earlier versions). >> So that will happen in the code of course, but we need the PEP to state >> clearly >> wether metadata 1.0 and 1.1 should be dropped by implementations or not. > > +1 > >>> It would be also incompatible with existing consumers that expect >>> a Python package to have an earlier version of the metadata. >>> Dropping 1.0 may be fine though - but again, this is out of scope >>> here. > > That's a software implementation issue. Not a metadata issue. Above you say that the PEP should specify whether to keep or drop 1.0 and 1.1, and now you say that whether dropping 1.0 is not a metadata issue (and, presumably, out of scope of the PEP)??? Regards, Martin ___ 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 Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull" wrote: > Martin's point is that the PEP process doesn't *have* "reference" > implementations. It has *sample* implementations. It may be useful > to refer to a sample implementation as an example.. Fair enough. But otoh, asking for sample implementations on this type of project can skew the PEP towards a particular implementation or product. A definition for metadata should be something quite abstract and self contained. So imo I am happier where it is currently. > What implementations do is another matter. Right. We all agree on that. > An implementation with lots of state like PyPI is not likely > to change quickly. As a matter of user relations (including but not > limited to developers like you), Python doesn't want to deprecate > practices that are expensive to change too soon. (That's not my > opinion about what is appropriate, that is my assessment of the > historical policy of Python, which I don't think will change.) Well I would need more convincing that it is better to do one PEP every 4-5 years as a user relations exercise than one PEP every year or two years. Whilst I agree that the core language is really great and the rate of progress can happily slow. It would be nice to see the rate of progress of other areas, such as the metadata side, increase a little. That wouldn't break policy David ___ 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: > > I am just describing the needs and the end user PoV with the reference > > implementation that happens to be used by *all* tools out there. > > That's good. That's what we need right now. Martin's point is that the PEP process doesn't *have* "reference" implementations. It has *sample* implementations. It may be useful to refer to a sample implementation as an example, but the PEP must *define* the behaviors without such references, and compare the behavior of the sample to the defined behavior. And references to internal details like function names is inappropriate in most cases; I assume that is Martin's point here. > > So that will happen in the code of course, but we need the PEP to > > state clearly wether metadata 1.0 and 1.1 should be dropped by > > implementations or not. > > +1 You can state what you want. What implementations do is another matter. An implementation with lots of state like PyPI is not likely to change quickly. As a matter of user relations (including but not limited to developers like you), Python doesn't want to deprecate practices that are expensive to change too soon. (That's not my opinion about what is appropriate, that is my assessment of the historical policy of Python, which I don't think will change.) ___ 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
Martin, As an application developer, I really stand with Tarek here. On Wed, 23 Dec 2009 20:07:30 +0100, Tarek Ziadé wrote: > 2009/12/23 "Martin v. Löwis" : >>> I think we want something stronger than that since they were not really >>> used by >>> the community and removed and replaced by something better. Using them >>> should raise a warning so developers abandon them, so it would be >>> "don't use 1.1 anymore" Yes. But that is a software warning message to be implemented within the installation software. The important thing is what is in the metadata. > I am just describing the needs and the end user PoV with the reference > implementation that happens to be used by *all* tools out there. That's good. That's what we need right now. > So that will happen in the code of course, but we need the PEP to state > clearly > wether metadata 1.0 and 1.1 should be dropped by implementations or not. +1 >> It would be also incompatible with existing consumers that expect >> a Python package to have an earlier version of the metadata. >> Dropping 1.0 may be fine though - but again, this is out of scope >> here. That's a software implementation issue. Not a metadata issue. > I don't understand why you are saying this is out of scope. Shouldn't we > state clearly in the PEP that 1.0 and 1.1 should not be used in the future I agree with you Tarek. Whilst we can suggest that the implementation be done in certain ways. The PEP in it's current form seems good enough an I am hoping it will go through soon. Three more years of deliberation and niggling on this PEP will have more of an adverse affect than a positive effect. It was started in 2005 and that seems like a long time to hold things up. There's always time for a 1.3 version in two years time if there is an unstoppable problem here - but I can't see any. As an application developer, I have to side with Tarek. Lets get this finalised. Thank you David ___ 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 that will happen in the code of course, but we need the PEP to state > clearly > wether metadata 1.0 and 1.1 should be dropped by implementations or not. Ok. We should recommend that implementations support these versions indefinitely. I see no point in dropping them. But then, this is really up to the implementations. >>> PEP 314 (PEP 345 predecessor) was implemented in a very particular manner: >> PEP 314 was implemented multiple times - not only in distutils, but also >> in PyPI (for example). > > PyPI doesn't produce PKG-INFO files AFAIK, it just consumes them, no ? Correct - but that's also an implementation of the PEP. > I am referring to the implementation in Distutils that produces 1.0 > *or* 1.1 PKG-INFO files. But it works both ways. Applications that consume then need to decide what versions they want to consume. >> Please do keep distutils out of PEP 345. The remaining occurrences >> (such as what the "interpret_marker" function does) should be removed. > > That's the reference implementation of a PEP 345 reader/writer that > happens to be in the stdlin. For what reason should we remove it from > the PEP ? Because there shouldn't be a reference implementation. If we have both a spec and an a reference implementation, then we need to define what happens in case they conflict. If the reference implementation is right, implementers of the PEP would *also* need to study the reference implementation to find out what conforming behaviour is. This is bad; the PEP should be the only definition of the metadata format. >>> This will be clearer I think. >> It would be also incompatible with existing consumers that expect >> a Python package to have an earlier version of the metadata. >> Dropping 1.0 may be fine though - but again, this is out of scope >> here. > > I don't understand why you are saying this is out of scope. Shouldn't we > state clearly in the PEP that 1.0 and 1.1 should not be used in the future ? In terms of conformance, what would that mean? If I implement 1.0 (in addition to also implementing 1.2), would I then be non-conforming (because the PEP says I should not support 1.0)? For PyPI, that would be fairly bad, as it will need to support earlier versions for many years to come (at a minimum, 10 years). Regards, Martin ___ 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/23 "Martin v. Löwis" : >> I think we want something stronger than that since they were not really used >> by >> the community and removed and replaced by something better. Using them >> should raise a warning so developers abandon them, so it would be >> "don't use 1.1 anymore" > > I think you are mixing the distutils implementation (and parameters > to the setup function) with PEP 345. This PEP *only* describes a > data format. As such, it is not capable of raising exceptions. I am just describing the needs and the end user PoV with the reference implementation that happens to be used by *all* tools out there. So that will happen in the code of course, but we need the PEP to state clearly wether metadata 1.0 and 1.1 should be dropped by implementations or not. >> PEP 314 (PEP 345 predecessor) was implemented in a very particular manner: > > PEP 314 was implemented multiple times - not only in distutils, but also > in PyPI (for example). PyPI doesn't produce PKG-INFO files AFAIK, it just consumes them, no ? I am referring to the implementation in Distutils that produces 1.0 *or* 1.1 PKG-INFO files. > >> If you do use options like 'requires' in Distutils' setup.py, your >> package ends up with a PKG-INFO Metadata v1.1. Otherwise it stays >> v1.0. > > Please do keep distutils out of PEP 345. The remaining occurrences > (such as what the "interpret_marker" function does) should be removed. That's the reference implementation of a PEP 345 reader/writer that happens to be in the stdlin. For what reason should we remove it from the PEP ? [..] > >> Once 1.2 is defined, we could deprecate the options that are >> corresponding to 1.1 at Distutils' level and make Distutils only >> produces metadata v1.2 PKG-INFO files (even if the options used by the >> developer could be written in a valid 1.0 format). >> >> This will be clearer I think. > > It would be also incompatible with existing consumers that expect > a Python package to have an earlier version of the metadata. > Dropping 1.0 may be fine though - but again, this is out of scope > here. I don't understand why you are saying this is out of scope. Shouldn't we state clearly in the PEP that 1.0 and 1.1 should not be used in the future ? Regards Tarek -- Tarek Ziadé | http://ziade.org ___ 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 we want something stronger than that since they were not really used > by > the community and removed and replaced by something better. Using them > should raise a warning so developers abandon them, so it would be > "don't use 1.1 anymore" I think you are mixing the distutils implementation (and parameters to the setup function) with PEP 345. This PEP *only* describes a data format. As such, it is not capable of raising exceptions. Whether you deprecate parameters to the setup function is an entirely different issue. Alternatives are removing them entirely, ignoring them, deprecating them, and conditionally accepting them (on the condition that they don't get mixed with parameters that are meant for 1.2 of the metadata). > PEP 314 (PEP 345 predecessor) was implemented in a very particular manner: PEP 314 was implemented multiple times - not only in distutils, but also in PyPI (for example). > If you do use options like 'requires' in Distutils' setup.py, your > package ends up with a PKG-INFO Metadata v1.1. Otherwise it stays > v1.0. Please do keep distutils out of PEP 345. The remaining occurrences (such as what the "interpret_marker" function does) should be removed. > In other words, v1.0 was not really superseded by v1.1. The latter was > just an alternative version and the current Distutils can produce > both depending on the options you use in your setup.py. That is all well, and should probably be extended into the implementation of PEP 345 in distutils. However, what specifically distutils does is really not the subject here. > Once 1.2 is defined, we could deprecate the options that are > corresponding to 1.1 at Distutils' level and make Distutils only > produces metadata v1.2 PKG-INFO files (even if the options used by the > developer could be written in a valid 1.0 format). > > This will be clearer I think. It would be also incompatible with existing consumers that expect a Python package to have an earlier version of the metadata. Dropping 1.0 may be fine though - but again, this is out of scope here. Regards, Martin ___ 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/23 "Martin v. Löwis" : >> The deprecation of the existing Requires/Provides/Obsoletes fields >> should be more prominent - tucked away below the examples, I missed >> these notices on the first read through (I only noticed that they >> actually had been formally deprecated when I got to the summary of >> differences at the end). I suggest placing the deprecation notice >> immediately after the relevant field headers. > > I would go beyond deprecation, and propose to remove them altogether. > > In the metadata format, there is no point in deprecating something. > If you have a valid use for these fields, use version 1.1. I think we want something stronger than that since they were not really used by the community and removed and replaced by something better. Using them should raise a warning so developers abandon them, so it would be "don't use 1.1 anymore" PEP 314 (PEP 345 predecessor) was implemented in a very particular manner: If you do use options like 'requires' in Distutils' setup.py, your package ends up with a PKG-INFO Metadata v1.1. Otherwise it stays v1.0. In other words, v1.0 was not really superseded by v1.1. The latter was just an alternative version and the current Distutils can produce both depending on the options you use in your setup.py. Once 1.2 is defined, we could deprecate the options that are corresponding to 1.1 at Distutils' level and make Distutils only produces metadata v1.2 PKG-INFO files (even if the options used by the developer could be written in a valid 1.0 format). This will be clearer I think. So, I am +1 for removing deprecated fields from PEP 345 and work on the deprecation issues at the code level in Distutils. Meaning Distutils' DistributionMetadata class will provide a way to read 1.0/1.1/1.2 but will only write 1.2 starting at 2.7/3.2, If a deprecated option is used, Distutils will produce a 1.1 with a warning. If a deprecated option is used together with a new option, like Require and Require-Dist, it will raise an error. Regards, Tarek ___ 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
