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'
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 thi
>> 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
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.
> 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.
> Env
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
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
de
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
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
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
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 state
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
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 s
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
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 wor
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 r
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
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 th
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 ex
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 version
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
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 relatio
-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 ~=
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
>
>
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.
> > 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
> ha
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 ma
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
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
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 m
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
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, sp
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
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
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-
> 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. :)
>> 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 specif
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 wo
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 transl
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
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 fo
> 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
___
> 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 counte
> 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 me
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
> 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
> he
> 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 u
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
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
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 d
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
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.
>>>
>>>
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 "
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
>>> introduc
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, not
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
> 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 u
> 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 o
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 spec
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 ambi
-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
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
-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
>> 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
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?
> 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
>> 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
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 asse
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
"
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
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 v
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".
>>
>> H
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
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
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: ~=
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
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
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 ve
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;
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" m
> 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
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.
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
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
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 mea
> 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 oper
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
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 metada
> 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
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
>
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
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 en
> 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
>>
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 samp
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
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 some
> 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 real
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
> 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 implement
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
1 - 100 of 106 matches
Mail list logo
