[Distutils] [RFC] PEP 345 and PEP 386 updates

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

M.-A. Lemburg wrote:
> Tarek Ziadé wrote:
>> On Wed, Oct 21, 2009 at 10:42 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>>> Tarek Ziadé wrote:
>>>> On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg <mal at egenix.com> 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.

The top-level Zope 2.12 distribution's doc/INSTALL.txt says:

 Supported [Python] versions include:

   * 2.5.x, (x >= 4)

   * 2.6.x

I *think* that the requirement for 2.5.4 is bogus, or at least I can't
figure out from SVN log etc. what specific bugfix would affect Zope.

There is no longer a "monolithic" build script which tries to check this
constraint, however:  the documented way to build Zope is either:

 $ virtualenv --no-site-packages /path/to/zope
 $ /path/to/zope/bin/easy_install \
    -i http://download.zope.org/Zope2/index/2.12 Zope2

or via zc.buildout:

  $ wget \
     http://pypi.python.org/packages/source/Z/Zope2/Zope2-2.12.0.tar.gz
  $ tar xfvz Zope2-2.12.0.tar.gz
  $ cd Zope2-2.12.0
  $ /path/to/your/python bootstrap/bootstrap.py
  $ bin/buildout



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at 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

iEUEARECAAYFAkrfLsQACgkQ+gerLs4ltQ4VPACdEiNlrPIgOFcM6Dzj6uZH7xH4
vHYAmMkPqqpzKagZVpIuHn2dV6j2G8Y=
=4ajI
-----END PGP SIGNATURE-----