You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Hett <st...@egosoft.com> on 2015/07/23 10:30:32 UTC
Re: 1.9.0 minimal Python version
Hi,
>>> - For 1.9, it's a little late to make any changes, but I would consider
>>> dropping py2.5 support (and converting to the 'except' 'as' syntax),
>>> since for 1.9 py3 support is more important than py2.5 support.
>>>
>>> Thoughts?
> I'd rather not mess with the 1.9 branch at this point ... we're so close
> to the release (I hope).
>
> -- Brane
as a thought for the 1.9 case:
In case you do not want to drop py2.5 support for 1.9 because it's
released stating that minimum support already, would it be an option to
still support py3 in a following patch (1.9.1)? For instance by
providing py-script versions for older as well as later versions?
Reasoning would be that given that SVN-versions have a lifetime of
roughly 2 years before the successive version is released it'd be quite
a limitation if that'd only work with a very old python version...
As an alternative approach: You'd also consider mentioning a minimum
requirement of python 2.6 just in the docs (no code changes yet) and
then release 1.9.1 with the actual "fixes". So technically then even
post release you would not change the minimal system requirements.
(just some thoughts from a user's point of view, if that input would be
of any benefit)
Regards,
Stefan
Re: 1.9.0 minimal Python version
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Philip Martin wrote on Fri, Jul 24, 2015 at 14:13:04 +0100:
> Philip Martin <ph...@wandisco.com> writes:
>
> > Philip Martin <ph...@wandisco.com> writes:
> >
> >> RHEL 6 is on Python 2.6 and is unlikely to change. Python 2.7 is
> >> available as a Red Hat Software Collection component.
> >
> > The Software Collection python27 is sufficient to build Subversion and
> > run the regression tests but some of the tests FAIL. The tests that
> > fail all install a python hook script and the hook script fails to run.
> > The reason is that the Software Collection relies on setting environment
> > variables to make the Python 2.7 binary and libraries available but
> > Subversion cleans the environment before running hooks.
>
> If tried using a script
>
> #!/bin/sh
> LD_LIBRARY_PATH=/opt/rh/python27/root/usr/lib64:$LD_LIBRARY_PATH /opt/rh/python27/root/usr/bin/python "$@"
>
> but it doesn't fix the FAILs as the hook scripts have an explict
>
> #!/opt/rh/python27/root/usr/bin/python
>
> The PYTHON setting in the Makefile is the path to the script and this is
> what we want in the hook.
You could fix that by making your wrapper script set Python's argv[0]
(at the C level) to the absolute path to the wrapper script. That'll
cause Python's sys.executable to be the wrapper script, which will make
the test harness write the path to the wrapper script in the #! line.
> We have a related, but sort of opposite, problem with parallel tests. I
> can use the script even if it is not found in PATH by doing:
>
> PYTHON=/path/to/script ./autogen.sh
> PYTHON=/path/to/script ./configure
> make check
>
> and the tests run (with the hook tests failing). If I attempt to run
> the tests in parallel
>
> make check PARALLEL=1
>
> then all the python tests SKIP because when the parallel code spawns
> additional python it uses the python found in PATH rather than the
> Makefile PYTHON.
IMO that's a bug, we shouldn't use the PATH python for subprocesses. We
should probably make the PARALLEL codepath use imp.load_module() like
run_tests() uses.
>
Cheers,
Daniel
Re: 1.9.0 minimal Python version
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> Philip Martin <ph...@wandisco.com> writes:
>
>> RHEL 6 is on Python 2.6 and is unlikely to change. Python 2.7 is
>> available as a Red Hat Software Collection component.
>
> The Software Collection python27 is sufficient to build Subversion and
> run the regression tests but some of the tests FAIL. The tests that
> fail all install a python hook script and the hook script fails to run.
> The reason is that the Software Collection relies on setting environment
> variables to make the Python 2.7 binary and libraries available but
> Subversion cleans the environment before running hooks.
If tried using a script
#!/bin/sh
LD_LIBRARY_PATH=/opt/rh/python27/root/usr/lib64:$LD_LIBRARY_PATH /opt/rh/python27/root/usr/bin/python "$@"
but it doesn't fix the FAILs as the hook scripts have an explict
#!/opt/rh/python27/root/usr/bin/python
The PYTHON setting in the Makefile is the path to the script and this is
what we want in the hook.
We have a related, but sort of opposite, problem with parallel tests. I
can use the script even if it is not found in PATH by doing:
PYTHON=/path/to/script ./autogen.sh
PYTHON=/path/to/script ./configure
make check
and the tests run (with the hook tests failing). If I attempt to run
the tests in parallel
make check PARALLEL=1
then all the python tests SKIP because when the parallel code spawns
additional python it uses the python found in PATH rather than the
Makefile PYTHON.
--
Philip Martin
WANdisco
Re: 1.9.0 minimal Python version
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> RHEL 6 is on Python 2.6 and is unlikely to change. Python 2.7 is
> available as a Red Hat Software Collection component.
The Software Collection python27 is sufficient to build Subversion and
run the regression tests but some of the tests FAIL. The tests that
fail all install a python hook script and the hook script fails to run.
The reason is that the Software Collection relies on setting environment
variables to make the Python 2.7 binary and libraries available but
Subversion cleans the environment before running hooks.
--
Philip Martin
WANdisco
Re: 1.9.0 minimal Python version
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> [please do not top-post]
>
> On 24.07.2015 11:00, Stefan Hett wrote:
>> In case that helps with the decision making process:
>> Debian 5.0 (lenny - no longer supported): py 2.5
>> Debian 6.0 (squeeze - current oldoldstable): py2.6
>> Debian 7.0/8.0/9.0 (wheezy/jessie/stretch - currently
>> oldstable/stable/testing): py2.7
>
> The "very old enterprise versions" are probably RHEL 6 and SuSE 10; both
> are still in wide use.
RHEL 6 is on Python 2.6 and is unlikely to change. Python 2.7 is
available as a Red Hat Software Collection component.
--
Philip Martin
WANdisco
Re: 1.9.0 minimal Python version
Posted by Branko Čibej <br...@wandisco.com>.
[please do not top-post]
On 24.07.2015 11:00, Stefan Hett wrote:
> In case that helps with the decision making process:
> Debian 5.0 (lenny - no longer supported): py 2.5
> Debian 6.0 (squeeze - current oldoldstable): py2.6
> Debian 7.0/8.0/9.0 (wheezy/jessie/stretch - currently
> oldstable/stable/testing): py2.7
The "very old enterprise versions" are probably RHEL 6 and SuSE 10; both
are still in wide use.
> So even this very conservative Linux distribution is supporting py2.7
> for the past two years (and with the backporting branch I assume even
> squeeze supports 2.7 which would make it a supported platform for the
> pat 4 years on that distribution).
>
> Source:
> https://packages.debian.org/search?keywords=python&searchon=names&suite=all§ion=all
>> On 23.07.2015 17:01, Bert Huijben wrote:
>>> I like this proposal... but I'm wondering in what case Linux build
>>> environments need python. Those very old enterprise versions are
>>> unlikely to have python 2.7 or newer.
>>
>> When building from a tarball, you only need Python to run the test suite.
>>
>> There are certain edge cases in the Python syntax where it's almost
>> impossible to be compatible with both 2.5/2.6 and 3.x. Because of
>> that, and because 2.6 is no longer supporter by the Python devs, it
>> makes sense to stop supporting those versions in 1.9/trunk.
>>
>> Those very old enterprise versions will just have to be upgraded, IMO.
>>
>>
>>> ------------------------------------------------------------------------
>>> From: Branko Čibej <ma...@wandisco.com>
>>> Sent: 23-7-2015 11:02
>>> To: dev@subversion.apache.org
>>> Subject: Re: 1.9.0 minimal Python version
>>>
>>> On 23.07.2015 10:30, Stefan Hett wrote:
>>> > Hi,
>>> >
>>> >>>> - For 1.9, it's a little late to make any changes, but I would
>>> >>>> consider
>>> >>>> dropping py2.5 support (and converting to the 'except' 'as'
>>> >>>> syntax),
>>> >>>> since for 1.9 py3 support is more important than py2.5 support.
>>> >>>>
>>> >>>> Thoughts?
>>> >> I'd rather not mess with the 1.9 branch at this point ... we're
>>> so close
>>> >> to the release (I hope).
>>> >>
>>> >> -- Brane
>>> > as a thought for the 1.9 case:
>>> > In case you do not want to drop py2.5 support for 1.9 because it's
>>> > released stating that minimum support already, would it be an option
>>> > to still support py3 in a following patch (1.9.1)? For instance by
>>> > providing py-script versions for older as well as later versions?
>>> >
>>> > Reasoning would be that given that SVN-versions have a lifetime of
>>> > roughly 2 years before the successive version is released it'd be
>>> > quite a limitation if that'd only work with a very old python
>>> version...
>>> >
>>> > As an alternative approach: You'd also consider mentioning a minimum
>>> > requirement of python 2.6 just in the docs (no code changes yet) and
>>> > then release 1.9.1 with the actual "fixes". So technically then even
>>> > post release you would not change the minimal system requirements.
>>> >
>>> > (just some thoughts from a user's point of view, if that input would
>>> > be of any benefit)
>>>
>>> Daniel and I have just been chatting about this on IRC, and we agreed
>>> that it makes sense to just drop 2.5/2.6 support for 1.9 and trunk; the
>>> proposal is that we declare support for 2.7, and at some point make
>>> 1.9.x and trunk compatible with both 2.7 and 3.x.
>>>
>>> -- Brane
>>
>
Re: 1.9.0 minimal Python version
Posted by Stefan Hett <st...@egosoft.com>.
In case that helps with the decision making process:
Debian 5.0 (lenny - no longer supported): py 2.5
Debian 6.0 (squeeze - current oldoldstable): py2.6
Debian 7.0/8.0/9.0 (wheezy/jessie/stretch - currently
oldstable/stable/testing): py2.7
So even this very conservative Linux distribution is supporting py2.7
for the past two years (and with the backporting branch I assume even
squeeze supports 2.7 which would make it a supported platform for the
pat 4 years on that distribution).
Source:
https://packages.debian.org/search?keywords=python&searchon=names&suite=all§ion=all
> On 23.07.2015 17:01, Bert Huijben wrote:
>> I like this proposal... but I'm wondering in what case Linux build
>> environments need python. Those very old enterprise versions are
>> unlikely to have python 2.7 or newer.
>
> When building from a tarball, you only need Python to run the test suite.
>
> There are certain edge cases in the Python syntax where it's almost
> impossible to be compatible with both 2.5/2.6 and 3.x. Because of
> that, and because 2.6 is no longer supporter by the Python devs, it
> makes sense to stop supporting those versions in 1.9/trunk.
>
> Those very old enterprise versions will just have to be upgraded, IMO.
>
>
>> ------------------------------------------------------------------------
>> From: Branko Čibej <ma...@wandisco.com>
>> Sent: 23-7-2015 11:02
>> To: dev@subversion.apache.org <ma...@subversion.apache.org>
>> Subject: Re: 1.9.0 minimal Python version
>>
>> On 23.07.2015 10:30, Stefan Hett wrote:
>> > Hi,
>> >
>> >>>> - For 1.9, it's a little late to make any changes, but I would
>> >>>> consider
>> >>>> dropping py2.5 support (and converting to the 'except' 'as'
>> >>>> syntax),
>> >>>> since for 1.9 py3 support is more important than py2.5 support.
>> >>>>
>> >>>> Thoughts?
>> >> I'd rather not mess with the 1.9 branch at this point ... we're so
>> close
>> >> to the release (I hope).
>> >>
>> >> -- Brane
>> > as a thought for the 1.9 case:
>> > In case you do not want to drop py2.5 support for 1.9 because it's
>> > released stating that minimum support already, would it be an option
>> > to still support py3 in a following patch (1.9.1)? For instance by
>> > providing py-script versions for older as well as later versions?
>> >
>> > Reasoning would be that given that SVN-versions have a lifetime of
>> > roughly 2 years before the successive version is released it'd be
>> > quite a limitation if that'd only work with a very old python
>> version...
>> >
>> > As an alternative approach: You'd also consider mentioning a minimum
>> > requirement of python 2.6 just in the docs (no code changes yet) and
>> > then release 1.9.1 with the actual "fixes". So technically then even
>> > post release you would not change the minimal system requirements.
>> >
>> > (just some thoughts from a user's point of view, if that input would
>> > be of any benefit)
>>
>> Daniel and I have just been chatting about this on IRC, and we agreed
>> that it makes sense to just drop 2.5/2.6 support for 1.9 and trunk; the
>> proposal is that we declare support for 2.7, and at some point make
>> 1.9.x and trunk compatible with both 2.7 and 3.x.
>>
>> -- Brane
>
Re: 1.9.0 minimal Python version
Posted by Branko Čibej <br...@wandisco.com>.
On 23.07.2015 17:01, Bert Huijben wrote:
> I like this proposal... but I'm wondering in what case Linux build
> environments need python. Those very old enterprise versions are
> unlikely to have python 2.7 or newer.
When building from a tarball, you only need Python to run the test suite.
There are certain edge cases in the Python syntax where it's almost
impossible to be compatible with both 2.5/2.6 and 3.x. Because of that,
and because 2.6 is no longer supporter by the Python devs, it makes
sense to stop supporting those versions in 1.9/trunk.
Those very old enterprise versions will just have to be upgraded, IMO.
> ------------------------------------------------------------------------
> From: Branko Čibej <ma...@wandisco.com>
> Sent: 23-7-2015 11:02
> To: dev@subversion.apache.org <ma...@subversion.apache.org>
> Subject: Re: 1.9.0 minimal Python version
>
> On 23.07.2015 10:30, Stefan Hett wrote:
> > Hi,
> >
> >>>> - For 1.9, it's a little late to make any changes, but I would
> >>>> consider
> >>>> dropping py2.5 support (and converting to the 'except' 'as'
> >>>> syntax),
> >>>> since for 1.9 py3 support is more important than py2.5 support.
> >>>>
> >>>> Thoughts?
> >> I'd rather not mess with the 1.9 branch at this point ... we're so
> close
> >> to the release (I hope).
> >>
> >> -- Brane
> > as a thought for the 1.9 case:
> > In case you do not want to drop py2.5 support for 1.9 because it's
> > released stating that minimum support already, would it be an option
> > to still support py3 in a following patch (1.9.1)? For instance by
> > providing py-script versions for older as well as later versions?
> >
> > Reasoning would be that given that SVN-versions have a lifetime of
> > roughly 2 years before the successive version is released it'd be
> > quite a limitation if that'd only work with a very old python version...
> >
> > As an alternative approach: You'd also consider mentioning a minimum
> > requirement of python 2.6 just in the docs (no code changes yet) and
> > then release 1.9.1 with the actual "fixes". So technically then even
> > post release you would not change the minimal system requirements.
> >
> > (just some thoughts from a user's point of view, if that input would
> > be of any benefit)
>
> Daniel and I have just been chatting about this on IRC, and we agreed
> that it makes sense to just drop 2.5/2.6 support for 1.9 and trunk; the
> proposal is that we declare support for 2.7, and at some point make
> 1.9.x and trunk compatible with both 2.7 and 3.x.
>
> -- Brane
RE: 1.9.0 minimal Python version
Posted by Bert Huijben <be...@qqmail.nl>.
I like this proposal... but I'm wondering in what case Linux build environments need python. Those very old enterprise versions are unlikely to have python 2.7 or newer.
Bert
-----Original Message-----
From: "Branko Čibej" <br...@wandisco.com>
Sent: 23-7-2015 11:02
To: "dev@subversion.apache.org" <de...@subversion.apache.org>
Subject: Re: 1.9.0 minimal Python version
On 23.07.2015 10:30, Stefan Hett wrote:
> Hi,
>
>>>> - For 1.9, it's a little late to make any changes, but I would
>>>> consider
>>>> dropping py2.5 support (and converting to the 'except' 'as'
>>>> syntax),
>>>> since for 1.9 py3 support is more important than py2.5 support.
>>>>
>>>> Thoughts?
>> I'd rather not mess with the 1.9 branch at this point ... we're so close
>> to the release (I hope).
>>
>> -- Brane
> as a thought for the 1.9 case:
> In case you do not want to drop py2.5 support for 1.9 because it's
> released stating that minimum support already, would it be an option
> to still support py3 in a following patch (1.9.1)? For instance by
> providing py-script versions for older as well as later versions?
>
> Reasoning would be that given that SVN-versions have a lifetime of
> roughly 2 years before the successive version is released it'd be
> quite a limitation if that'd only work with a very old python version...
>
> As an alternative approach: You'd also consider mentioning a minimum
> requirement of python 2.6 just in the docs (no code changes yet) and
> then release 1.9.1 with the actual "fixes". So technically then even
> post release you would not change the minimal system requirements.
>
> (just some thoughts from a user's point of view, if that input would
> be of any benefit)
Daniel and I have just been chatting about this on IRC, and we agreed
that it makes sense to just drop 2.5/2.6 support for 1.9 and trunk; the
proposal is that we declare support for 2.7, and at some point make
1.9.x and trunk compatible with both 2.7 and 3.x.
-- Brane
Re: 1.9.0 minimal Python version
Posted by Branko Čibej <br...@wandisco.com>.
On 23.07.2015 10:30, Stefan Hett wrote:
> Hi,
>
>>>> - For 1.9, it's a little late to make any changes, but I would
>>>> consider
>>>> dropping py2.5 support (and converting to the 'except' 'as'
>>>> syntax),
>>>> since for 1.9 py3 support is more important than py2.5 support.
>>>>
>>>> Thoughts?
>> I'd rather not mess with the 1.9 branch at this point ... we're so close
>> to the release (I hope).
>>
>> -- Brane
> as a thought for the 1.9 case:
> In case you do not want to drop py2.5 support for 1.9 because it's
> released stating that minimum support already, would it be an option
> to still support py3 in a following patch (1.9.1)? For instance by
> providing py-script versions for older as well as later versions?
>
> Reasoning would be that given that SVN-versions have a lifetime of
> roughly 2 years before the successive version is released it'd be
> quite a limitation if that'd only work with a very old python version...
>
> As an alternative approach: You'd also consider mentioning a minimum
> requirement of python 2.6 just in the docs (no code changes yet) and
> then release 1.9.1 with the actual "fixes". So technically then even
> post release you would not change the minimal system requirements.
>
> (just some thoughts from a user's point of view, if that input would
> be of any benefit)
Daniel and I have just been chatting about this on IRC, and we agreed
that it makes sense to just drop 2.5/2.6 support for 1.9 and trunk; the
proposal is that we declare support for 2.7, and at some point make
1.9.x and trunk compatible with both 2.7 and 3.x.
-- Brane