[RFC] PEP 345 and PEP 386 updates

[Tarek Ziadé]

Hi,

PEP 345 is the PEP for the new metadata format, replacing PEP 314. I
have upgraded it, using Tres's work from last year, and the next step
is to add the context marker presented in PEP 390.

I have also updated PEP 386 to link it to PEP 345.

= PEP 345 : Summary of Differences From PEP 314 =

* Metadata-Version is now 1.2.

* Added fields:

  - Maintainer
  - Maintainer-email
  - Requires-Python
  - Requires-External
  - Requires-Dist
  - Provides-Dist
  - Obsoletes-Dist

* Deprecated fields:

  - Requires (in favor of Requires-Dist)
  - Provides (in favor of Provides-Dist)
  - Obsoletes (in favor of Obsoletes-Dist)


Please comment!

Tarek
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[M.-A. Lemburg]

Tarek Ziadé wrote:

> Hi,
>
> PEP 345 is the PEP for the new metadata format, replacing PEP 314. I
> have upgraded it, using Tres's work from last year, and the next step
> is to add the context marker presented in PEP 390.
>
> I have also updated PEP 386 to link it to PEP 345.
>
> = PEP 345 : Summary of Differences From PEP 314 =
>
> * Metadata-Version is now 1.2.
>
> * Added fields:
>
>   - Maintainer
>   - Maintainer-email
>   - Requires-Python
>   - Requires-External
>   - Requires-Dist
>   - Provides-Dist
>   - Obsoletes-Dist
>
> * Deprecated fields:
>
>   - Requires (in favor of Requires-Dist)
>   - Provides (in favor of Provides-Dist)
>   - Obsoletes (in favor of Obsoletes-Dist)

Where's the benefit of renaming the above three fields ?

After all, the meta-data format is a distutils specific format,
so the extra "-Dist" qualifier appears unnecessary.

I'd also remove the "Requires-" from "Requires-Python" and
simply use "Python" as field name. The intent should be clear,
e.g. for Python 2 packages that need at least 2.6:

Python: >2.6, <3.0

I'd also like to suggest the addition of conditional field
values as already discussed in private mail. This would
allow defining requirements based on the target platform
and use the same micro-language as suggested in PEP 390.

Here's a sketch (following Python's inline if syntax and the
example from PEP 390):

requires: pywin32; if sys_platform == 'win32'
requires: bar (>1.0); if sys_platform == 'win32'
requires: foo; if platform_machine == 'i386'
requires: bar; if python_version == '2.4' or python_version == '2.5'
requires: baz; if 'linux' in sys_platform

Each of the listed requires field entries only applies if the
condition matches the target platform.

The micro-language should provide a limited number of
variables to use on the conditions:

python_version = sys.version
sys_platform = sys.platform
os_name = os.name
platform_machine = platform.machine()
platform_version = platform.version()

and possibly more.

The same notation could also be used in setup() keyword
parameters for the meta-data fields, e.g.

setup(..., requires=["pywin32; if sys_platform == 'win32'"], ...)

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 20 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Fred Drake]

On Tue, Oct 20, 2009 at 7:37 AM, M.-A. Lemburg <mal@...> wrote:
> Where's the benefit of renaming the above three fields ?

I don't see any benefit here either; if we want to add fields for
Python package or anything else, new (more explicit) field names can
be added, without ever requiring these to be changed.

As much as having more explicit names would be nice, it's not worth
the disruption caused by deprecation cycles, or the accompanying
confusion.  These sorts of changes have very long uptake, while the
clarity benefit is close to non-existent.

> I'd also remove the "Requires-" from "Requires-Python" and
> simply use "Python" as field name.

+0

> The micro-language should provide a limited number of
> variables to use on the conditions:
>
> python_version = sys.version
> sys_platform = sys.platform

If we adopt such a micro-language (I'm reserving judgment until I've
had more time to read the relevant PEPs carefully), I'd rather see the
names match what's in the Python runtime more closely, probably only
avoiding the call syntax.

This would make the examples:

  requires: pywin32; if sys.platform == 'win32'
  requires: bar (>1.0); if sys.platform == 'win32'
  requires: foo; if platform.machine == 'i386'
  requires: bar; if sys.version == '2.4' or sys.version == '2.5'
  requires: baz; if 'linux' in sys.platform

> The same notation could also be used in setup() keyword
> parameters for the meta-data fields, e.g.

Whatever notation is adopted should be used consistently.


  -Fred

--
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Floris Bruynooghe-2]

On Tue, Oct 20, 2009 at 01:37:48PM +0200, M.-A. Lemburg wrote:
[...]
> > * Added fields:
[...]

> >   - Requires-Dist
> >   - Provides-Dist
> >   - Obsoletes-Dist
> >
> > * Deprecated fields:
> >
> >   - Requires (in favor of Requires-Dist)
> >   - Provides (in favor of Provides-Dist)
> >   - Obsoletes (in favor of Obsoletes-Dist)
>
> Where's the benefit of renaming the above three fields ?
>
> After all, the meta-data format is a distutils specific format,
> so the extra "-Dist" qualifier appears unnecessary.

In PEP 314 the "Requires" field is meant to contain module or packages
names.  Now OTOH it seems people are more interested in the
distribution names.  Making this change explicit is a good thing I
reckon.

(There's a whole other discussion about how it would be easier to
provide an alternative implementation if it was done on module/package
name instead of distribution name, but I haven't got enough experience
with that so am happy to go with what actually seems to be used now.)

Regards
Floris

--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[M.-A. Lemburg]

Fred Drake wrote:

> On Tue, Oct 20, 2009 at 7:37 AM, M.-A. Lemburg <mal@...> wrote:
>> Where's the benefit of renaming the above three fields ?
>
> I don't see any benefit here either; if we want to add fields for
> Python package or anything else, new (more explicit) field names can
> be added, without ever requiring these to be changed.
>
> As much as having more explicit names would be nice, it's not worth
> the disruption caused by deprecation cycles, or the accompanying
> confusion.  These sorts of changes have very long uptake, while the
> clarity benefit is close to non-existent.
>
>> I'd also remove the "Requires-" from "Requires-Python" and
>> simply use "Python" as field name.
>
> +0
>
>> The micro-language should provide a limited number of
>> variables to use on the conditions:
>>
>> python_version = sys.version
>> sys_platform = sys.platform
>
> If we adopt such a micro-language (I'm reserving judgment until I've
> had more time to read the relevant PEPs carefully), I'd rather see the
> names match what's in the Python runtime more closely, probably only
> avoiding the call syntax.

We could do that as well, yes.

> This would make the examples:
>
>   requires: pywin32; if sys.platform == 'win32'
>   requires: bar (>1.0); if sys.platform == 'win32'
>   requires: foo; if platform.machine == 'i386'
>   requires: bar; if sys.version == '2.4' or sys.version == '2.5'
>   requires: baz; if 'linux' in sys.platform
>
>> The same notation could also be used in setup() keyword
>> parameters for the meta-data fields, e.g.
>
> Whatever notation is adopted should be used consistently.

Agreed.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 20 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[David Lyon]

On Tue, 20 Oct 2009 09:36:08 -0400, Fred Drake <fdrake@...> wrote:

> If we adopt such a micro-language (I'm reserving judgment until I've
> had more time to read the relevant PEPs carefully), I'd rather see the
> names match what's in the Python runtime more closely, probably only
> avoiding the call syntax.
> ..
>   requires: pywin32; if sys.platform == 'win32'
> ..

I foresee problems with using constants from the python runtime as
they currently stand. Only for the simple reason that the existing
'constants' were good 5 years ago. But won't be good - next year.

For example, 'win32' refers to a specific windows because windows
can now be 64 bit.

Does win32 mean win64? It does now - but it shouldn't.

I propose windows and 32 and 64 as further qualifiers. So for example,
'windows' or 'windows-32' or 'windows-64'. Not to mention 'windows-xp-32'
and 'windows-xp-64' and 'windows-ce'.

Maybe windows-128 is around the corner - who knows..

I respect those sys python constants.. but they are too unspecific
to be used here.

And for linux, what is 'linux2' ? It should just be linux.. to
make it less confusing.

Anyway, I'm coding this all up now into an example.

So far I have in my table..

standard_platform_bits = ('windows','linux','mac',
                          'xp','vista','7','ce'
                          'os/x',
                          '32','64',
                          'kde','gnome',
                          'wx','gtk',
                          'ubuntu','debian','suse','redhat','gentoo',
                          'centos','symbian'
                          )

I think we need new constants for package installation. It
will be less confusing. Whichever way we go.

David


_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

On Tue, Oct 20, 2009 at 9:33 PM, David Lyon <david.lyon@...> wrote:

> On Tue, 20 Oct 2009 09:36:08 -0400, Fred Drake <fdrake@...> wrote:
>
>> If we adopt such a micro-language (I'm reserving judgment until I've
>> had more time to read the relevant PEPs carefully), I'd rather see the
>> names match what's in the Python runtime more closely, probably only
>> avoiding the call syntax.
>> ..
>>   requires: pywin32; if sys.platform == 'win32'
>> ..
>
> I foresee problems with using constants from the python runtime as
> they currently stand. Only for the simple reason that the existing
> 'constants' were good 5 years ago. But won't be good - next year.
>
> For example, 'win32' refers to a specific windows because windows
> can now be 64 bit.
>
> Does win32 mean win64? It does now - but it shouldn't.
>
> I propose windows and 32 and 64 as further qualifiers. So for example,
> 'windows' or 'windows-32' or 'windows-64'. Not to mention 'windows-xp-32'
> and 'windows-xp-64' and 'windows-ce'.
>
> Maybe windows-128 is around the corner - who knows..
>
> I respect those sys python constants.. but they are too unspecific
> to be used here.

No, the architecture is given by platform.machine() so you have it already,
by combining a test with sys.platform.


>
> And for linux, what is 'linux2' ? It should just be linux.. to
> make it less confusing.

That's how the platform is called, that's not created by Python (it's
what uname -s returns)

see http://docs.python.org/library/sys.html

Tarek.
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg <mal@...> wrote:

>>> The micro-language should provide a limited number of
>>> variables to use on the conditions:
>>>
>>> python_version = sys.version
>>> sys_platform = sys.platform
>>
>> If we adopt such a micro-language (I'm reserving judgment until I've
>> had more time to read the relevant PEPs carefully), I'd rather see the
>> names match what's in the Python runtime more closely, probably only
>> avoiding the call syntax.
>
> We could do that as well, yes.

+1 on close names + no call syntax

but, notice that "python_version" here is:   "%s.%s" %
sys.version_info[0], sys.version_info[1]

thats why we came up with that name, to disinguish it from sys.version
(that contains more stuff)

Tarek
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Eric Smith-22]

Tarek Ziadé wrote:
> but, notice that "python_version" here is:   "%s.%s" %
> sys.version_info[0], sys.version_info[1]

I think you mean:
"{0[0]}.{0[1]}".format(sys.version_info)
or better:
"{0.major}.{0.minor}".format(sys.version_info)

:)
On the odd occasion that .format is less verbose than %, I like pointing
it out!

Eric.
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

On Tue, Oct 20, 2009 at 10:20 PM, Eric Smith <eric@...> wrote:

> Tarek Ziadé wrote:
>>
>> but, notice that "python_version" here is:   "%s.%s" %
>> sys.version_info[0], sys.version_info[1]
>
> I think you mean:
> "{0[0]}.{0[1]}".format(sys.version_info)
> or better:
> "{0.major}.{0.minor}".format(sys.version_info)
>
> :)
> On the odd occasion that .format is less verbose than %, I like pointing it
> out!

Ah yes, that's nicer :)
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[cdavid]

Tarek Ziadé wrote:
> No, the architecture is given by platform.machine() so you have it already,
> by combining a test with sys.platform.

But platform.machine() returns a 32 bits machine if you run 32 bits
python on 64 bits windows. AFAIK, the only reliable way is to use the
win32 API:

http://blogs.msdn.com/oldnewthing/archive/2005/02/01/364563.aspx

In scons (where we limit ourself to pure python code ATM), we tried the
registry, but this is not reliable (some braindead softwares install
WoW64 registry keys even on 32 bits windows). OTOH, I guess not that
many applications need this information: after all, the whole point of
WoW64 is to virtualize 32 bits applications so that they believe to run
on a conventional 32 bits python.

David
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

On Wed, Oct 21, 2009 at 3:45 AM, David Cournapeau
<david@...> wrote:

> Tarek Ziadé wrote:
>> No, the architecture is given by platform.machine() so you have it already,
>> by combining a test with sys.platform.
>
> But platform.machine() returns a 32 bits machine if you run 32 bits
> python on 64 bits windows. AFAIK, the only reliable way is to use the
> win32 API:
>
> http://blogs.msdn.com/oldnewthing/archive/2005/02/01/364563.aspx
>
> In scons (where we limit ourself to pure python code ATM), we tried the
> registry, but this is not reliable (some braindead softwares install
> WoW64 registry keys even on 32 bits windows). OTOH, I guess not that
> many applications need this information: after all, the whole point of
> WoW64 is to virtualize 32 bits applications so that they believe to run
> on a conventional 32 bits python.

There's something unclear for me here :

What is suppose to happen when you use Python 32bits on a 64bits machine,
for Python distributions that get build or installed ?

Do you end up in a mixed environment of 64bits distributions within a
32bits interpreter ?
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[cdavid]

Tarek Ziadé wrote:
> There's something unclear for me here :
>
> What is suppose to happen when you use Python 32bits on a 64bits machine,
> for Python distributions that get build or installed ?
>
> Do you end up in a mixed environment of 64bits distributions within a
> 32bits interpreter ?
>  

Hopefully not - you obviously cannot load 64 bits extensions in a 32
bits interpreter. I don't know the details, but WoW64 virtualizes
everything to look like a 32 bits windows to 32 bits processes (the
registry is different, etc...). But you could imagine that independently
on whether the interpreter is 32 or 64 bits, you need to process things
differently on windows 32 and 64 bits (e.g. a 32 bits python on xp and a
32 bits python on xp 64 may have different requirements). FWIW, the
user-case in scons was detecting Visual Studio.

David

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[M.-A. Lemburg]

Tarek Ziadé wrote:

> On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg <mal@...> wrote:
>>>> The micro-language should provide a limited number of
>>>> variables to use on the conditions:
>>>>
>>>> python_version = sys.version
>>>> sys_platform = sys.platform
>>>
>>> If we adopt such a micro-language (I'm reserving judgment until I've
>>> had more time to read the relevant PEPs carefully), I'd rather see the
>>> names match what's in the Python runtime more closely, probably only
>>> avoiding the call syntax.
>>
>> We could do that as well, yes.
>
> +1 on close names + no call syntax
>
> but, notice that "python_version" here is:   "%s.%s" %
> sys.version_info[0], sys.version_info[1]
>
> thats why we came up with that name, to disinguish it from sys.version
> (that contains more stuff)

I think we do need the full version here, so perhaps using
sys.version.split()[0] would be better or simply the full
version string and then have conditions use >=, <=, <, >
only (ie. not =, since that would likely never match).

Note that packages do sometimes need to know that a certain
Python patch level release is installed (e.g. Zope often has
had this need) and a proper dependency checker would have to
detect a possible mismatch.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 21 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

On Wed, Oct 21, 2009 at 10:20 AM, David Cournapeau
<david@...> wrote:

> Tarek Ziadé wrote:
>> There's something unclear for me here :
>>
>> What is suppose to happen when you use Python 32bits on a 64bits machine,
>> for Python distributions that get build or installed ?
>>
>> Do you end up in a mixed environment of 64bits distributions within a
>> 32bits interpreter ?
>>
>
> Hopefully not - you obviously cannot load 64 bits extensions in a 32
> bits interpreter. I don't know the details, but WoW64 virtualizes
> everything to look like a 32 bits windows to 32 bits processes (the
> registry is different, etc...). But you could imagine that independently
> on whether the interpreter is 32 or 64 bits, you need to process things
> differently on windows 32 and 64 bits (e.g. a 32 bits python on xp and a
> 32 bits python on xp 64 may have different requirements). FWIW, the
> user-case in scons was detecting Visual Studio.

The micro-language, though, is about the metadata fields like "requires"

So do you have a use case where a Python distribution needs to use "64
bit (the machine)"
in order to provide a different requires ?

Tarek
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[cdavid]

Tarek Ziadé wrote:
> The micro-language, though, is about the metadata fields like "requires"
>
> So do you have a use case where a Python distribution needs to use "64
> bit (the machine)"
>  

Given the difficulty, I think such a field should only be added once
python itself has a method to reliably detect windows 64, to avoid any
inconsistencies.

David

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

On Wed, Oct 21, 2009 at 10:58 AM, David Cournapeau
<david@...> wrote:

> Tarek Ziadé wrote:
>> The micro-language, though, is about the metadata fields like "requires"
>>
>> So do you have a use case where a Python distribution needs to use "64
>> bit (the machine)"
>>
>
> Given the difficulty, I think such a field should only be added once
> python itself has a method to reliably detect windows 64, to avoid any
> inconsistencies.

Ok then. Notice that introducing new variables afterwards in the
micro-language will be easy


Tarek
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[Tarek Ziadé]

On Wed, Oct 21, 2009 at 10:42 AM, M.-A. Lemburg <mal@...> wrote:

> Tarek Ziadé wrote:
>> On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg <mal@...> wrote:
>>>>> The micro-language should provide a limited number of
>>>>> variables to use on the conditions:
>>>>>
>>>>> python_version = sys.version
>>>>> sys_platform = sys.platform
>>>>
>>>> If we adopt such a micro-language (I'm reserving judgment until I've
>>>> had more time to read the relevant PEPs carefully), I'd rather see the
>>>> names match what's in the Python runtime more closely, probably only
>>>> avoiding the call syntax.
>>>
>>> We could do that as well, yes.
>>
>> +1 on close names + no call syntax
>>
>> but, notice that "python_version" here is:   "%s.%s" %
>> sys.version_info[0], sys.version_info[1]
>>
>> thats why we came up with that name, to disinguish it from sys.version
>> (that contains more stuff)
>
> I think we do need the full version here, so perhaps using
> sys.version.split()[0] would be better or simply the full
> version string and then have conditions use >=, <=, <, >
> only (ie. not =, since that would likely never match).

Notice that for the comparisons >, < to work, that requires more than string
comparisons in case we provide the ability to work with rc versions, because:

>>> '2.6.3rc4' < '2.6.3'
False

We said earlier that we could use sys.hexversion to handle this, but otherwise,
at least for the Python version, we can use the StrictVersion() class
from Distutils,

*But* we ended up thinking that it would be better for the first version to keep
just "==", "!=", "in" and "not in" operators and a MAJOR.MINOR string.

These are enough just to compare strings, on a limited number of
versions for Python.

What use case you have in mind for a three numbers version ?

>
> Note that packages do sometimes need to know that a certain
> Python patch level release is installed (e.g. Zope often has
> had this need) and a proper dependency checker would have to
> detect a possible mismatch.

I see. I would rather have this patch info in another variable, and restrict
the micro language capabilities as much as possible.

Any hint were Zope does this ?

Regards
Tarek
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[M.-A. Lemburg]

Tarek Ziadé wrote:

> On Wed, Oct 21, 2009 at 10:42 AM, M.-A. Lemburg <mal@...> wrote:
>> Tarek Ziadé wrote:
>>> On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg <mal@...> wrote:
>>>>>> The micro-language should provide a limited number of
>>>>>> variables to use on the conditions:
>>>>>>
>>>>>> python_version = sys.version
>>>>>> sys_platform = sys.platform
>>>>>
>>>>> If we adopt such a micro-language (I'm reserving judgment until I've
>>>>> had more time to read the relevant PEPs carefully), I'd rather see the
>>>>> names match what's in the Python runtime more closely, probably only
>>>>> avoiding the call syntax.
>>>>
>>>> We could do that as well, yes.
>>>
>>> +1 on close names + no call syntax
>>>
>>> but, notice that "python_version" here is:   "%s.%s" %
>>> sys.version_info[0], sys.version_info[1]
>>>
>>> thats why we came up with that name, to disinguish it from sys.version
>>> (that contains more stuff)
>>
>> I think we do need the full version here, so perhaps using
>> sys.version.split()[0] would be better or simply the full
>> version string and then have conditions use >=, <=, <, >
>> only (ie. not =, since that would likely never match).
>
> Notice that for the comparisons >, < to work, that requires more than string
> comparisons in case we provide the ability to work with rc versions, because:
>
>>>> '2.6.3rc4' < '2.6.3'
> False
>
> We said earlier that we could use sys.hexversion to handle this, but otherwise,
> at least for the Python version, we can use the StrictVersion() class
> from Distutils,
>
> *But* we ended up thinking that it would be better for the first version to keep
> just "==", "!=", "in" and "not in" operators and a MAJOR.MINOR string.
>
> These are enough just to compare strings, on a limited number of
> versions for Python.

Ok.

> What use case you have in mind for a three numbers version ?

This may occur when you for example rely on PyXML, elementtree
or simplejson which are also available as external packages
(with a different release cycle).

E.g. say there's a bug in the JSON package included in Python
versions 2.6.0, 2.6.1, 2.6.2 which is fixed in 2.6.3 and has
also been fixed in the PyPI version of the package.

Now say that a system ships with 2.6.1 as Python version.

For Python versions with the bug, you'd add a requirement for
the external package in order to work around the bug in the
system installation of Python. For Python versions >= 2.6.3,
you'd continue to use the package from the system provided
Python installation.

It's a rather rare use case, so just something to think
about for a future revision of the proposal.

>> Note that packages do sometimes need to know that a certain
>> Python patch level release is installed (e.g. Zope often has
>> had this need) and a proper dependency checker would have to
>> detect a possible mismatch.
>
> I see. I would rather have this patch info in another variable, and restrict
> the micro language capabilities as much as possible.
>
> Any hint were Zope does this ?

Early Zope versions simply warned about the problem in the
release documentation. IIRC, later versions actually tested
the installed Python version and warned about issues during
the installation process.

I'm not sure how Zope 2.12 with all the tiny little packages
handles this case.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 21 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig

[cdavid]

Tarek Ziadé wrote:

> We said earlier that we could use sys.hexversion to handle this, but otherwise,
> at least for the Python version, we can use the StrictVersion() class
> from Distutils,
>
> *But* we ended up thinking that it would be better for the first version to keep
> just "==", "!=", "in" and "not in" operators and a MAJOR.MINOR string.
>
> These are enough just to compare strings, on a limited number of
> versions for Python.
>
> What use case you have in mind for a three numbers version ?

Although it is best to avoid depending on micro number, one recent
use-case I can think about is the added MSVC runtime information at
python level (between python 2.6.1 and 2.6.2), which we use in numpy to
make sure we link the exact same C runtime as python.

David

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@...
http://mail.python.org/mailman/listinfo/distutils-sig