-----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 <m...@egenix.com> wrote:
>>> Tarek Ziadé wrote:
>>>> On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg <m...@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 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
iEUEARECAAYFAkrfLsQACgkQ+gerLs4ltQ4VPACdEiNlrPIgOFcM6Dzj6uZH7xH4
vHYAmMkPqqpzKagZVpIuHn2dV6j2G8Y=
=4ajI
-----END PGP SIGNATURE-----
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
