You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2020/05/15 17:19:43 UTC
py2.7 used by default when py2 and py3 are both available
I just noticed that when I ran «make check» on trunk, it was run using
python 2.7. I hadn't pass any Python-related flags to autogen.sh/configure.
I presume py2.7 was used because build/find_python.sh used whatever the
"python" executable in my $PATH is.
Looking at find_python.sh, that's exactly what it does. Shouldn't we
change it to use Python 3 in preference to Python 2, given that we've
documented py2 as no longer supported?
Cheers,
Daniel
Re: Change build/find_python.sh and roll 1.14.0-rc3? (was: Re:
py2.7 used by default when py2 and py3 are both available)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Sat, 16 May 2020 13:46 +0200:
> On 16.05.2020 12:00, Stefan Sperling wrote:
> > On Fri, May 15, 2020 at 09:13:38PM +0000, Daniel Shahaf wrote:
> >> IIRC the soak was to end on Wednesday and any change requires at least
> >> a week's extension.
> >>
> >> Here's the patch. I smoke tested it and it passed, but I'm seeing tests
> >> randomly fail even in unpatched trunk so I can't an unqualified +1.
> > I would prefer if we just nominated this for 1.14.1 as usual.
> >
> > This is something that is very, very easy to work around for packagers.
> > And I don't think we are seeing a lot of people making their own builds
> > from source these days, anyway. And even then, in the worst case they ask
> > for help and it's easy to solve.
> >
> > So I see no reason to fix this for .0, not even with the hypothetical case
> > in mind where we would drop python2 support to a stronger degree than
> > we already have.
> >
> > If it is deemed very important, we could just document this in release
> > notes under "Known issues" until 1.14.1 comes out.
>
> Sure, that makes sense, too. After all, we have a bunch of
> python-releated fixes already on trunk that are easily candidates for .1.
Done in r1877835. Revisions welcome. ☺
Re: Change build/find_python.sh and roll 1.14.0-rc3? (was: Re: py2.7
used by default when py2 and py3 are both available)
Posted by Branko Čibej <br...@apache.org>.
On 16.05.2020 12:00, Stefan Sperling wrote:
> On Fri, May 15, 2020 at 09:13:38PM +0000, Daniel Shahaf wrote:
>> IIRC the soak was to end on Wednesday and any change requires at least
>> a week's extension.
>>
>> Here's the patch. I smoke tested it and it passed, but I'm seeing tests
>> randomly fail even in unpatched trunk so I can't an unqualified +1.
> I would prefer if we just nominated this for 1.14.1 as usual.
>
> This is something that is very, very easy to work around for packagers.
> And I don't think we are seeing a lot of people making their own builds
> from source these days, anyway. And even then, in the worst case they ask
> for help and it's easy to solve.
>
> So I see no reason to fix this for .0, not even with the hypothetical case
> in mind where we would drop python2 support to a stronger degree than
> we already have.
>
> If it is deemed very important, we could just document this in release
> notes under "Known issues" until 1.14.1 comes out.
Sure, that makes sense, too. After all, we have a bunch of
python-releated fixes already on trunk that are easily candidates for .1.
-- Brane
Re: Change build/find_python.sh and roll 1.14.0-rc3? (was: Re: py2.7
used by default when py2 and py3 are both available)
Posted by Stefan Sperling <st...@elego.de>.
On Fri, May 15, 2020 at 09:13:38PM +0000, Daniel Shahaf wrote:
> IIRC the soak was to end on Wednesday and any change requires at least
> a week's extension.
>
> Here's the patch. I smoke tested it and it passed, but I'm seeing tests
> randomly fail even in unpatched trunk so I can't an unqualified +1.
I would prefer if we just nominated this for 1.14.1 as usual.
This is something that is very, very easy to work around for packagers.
And I don't think we are seeing a lot of people making their own builds
from source these days, anyway. And even then, in the worst case they ask
for help and it's easy to solve.
So I see no reason to fix this for .0, not even with the hypothetical case
in mind where we would drop python2 support to a stronger degree than
we already have.
If it is deemed very important, we could just document this in release
notes under "Known issues" until 1.14.1 comes out.
Change build/find_python.sh and roll 1.14.0-rc3? (was: Re: py2.7
used by default when py2 and py3 are both available)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
[Changing the subject for visibility.]
Branko Čibej wrote on Fri, May 15, 2020 at 22:02:53 +0200:
> On 15.05.2020 20:42, Daniel Shahaf wrote:
> > Branko Čibej wrote on Fri, 15 May 2020 18:14 +00:00:
> >> [...]
> >
> > The documentation <https://subversion.apache.org/docs/release-notes/1.14#python2>
> > reads:
> >
> > """This means that although Subversion 1.14.0 still technically works
> > with Python 2.7, any later 1.14.x point release may drop this
> > support if it becomes too difficult to maintain."""
> >
> >> It would make sense to prefer Python3 over Python2 by default if both
> >> are available, but I wouldn't go further than that. The order of
> >> executable names should be [python3, python, python2], IIUC the naming
> >> conventions.
> > Sounds good to me.
> >
> > If we make this change, should we roll an rc3 for it?
>
> It's a pure build script change, but it's always nice to be able to
> essentially rename the RC to the release (except for svn_version.h
> changes). I don't think we have to restart the soak, though.
>
IIRC the soak was to end on Wednesday and any change requires at least
a week's extension.
Here's the patch. I smoke tested it and it passed, but I'm seeing tests
randomly fail even in unpatched trunk so I can't an unqualified +1.
[[[
Index: build/find_python.sh
===================================================================
--- build/find_python.sh (revision 1877789)
+++ build/find_python.sh (working copy)
@@ -23,7 +23,7 @@
# Required version of Python
VERSION=${1:-0x2070000}
-for pypath in "$PYTHON" "$PYTHON2" "$PYTHON3" python python2 python3; do
+for pypath in "$PYTHON3" "$PYTHON" "$PYTHON2" python3 python python2; do
if [ "x$pypath" != "x" ]; then
DETECT_PYTHON="import sys;sys.exit((sys.hexversion < $VERSION) and 1 or 0)"
if "$pypath" -c "$DETECT_PYTHON" >/dev/null 2>/dev/null; then
]]]
> > Otherwise, if we
> > in fact pull py2.7 support at some point (as the release notes allow us
> > to), we'd find ourselves having to bump a dependency's major version in
> > a patch release.
>
> True.
Cheers,
Daniel
Re: py2.7 used by default when py2 and py3 are both available
Posted by Branko Čibej <br...@apache.org>.
On 15.05.2020 20:42, Daniel Shahaf wrote:
> Branko Čibej wrote on Fri, 15 May 2020 18:14 +00:00:
>> On 15.05.2020 19:19, Daniel Shahaf wrote:
>>> I just noticed that when I ran «make check» on trunk, it was run using
>>> python 2.7. I hadn't pass any Python-related flags to autogen.sh/configure.
>>>
>>> I presume py2.7 was used because build/find_python.sh used whatever the
>>> "python" executable in my $PATH is.
>>>
>>> Looking at find_python.sh, that's exactly what it does. Shouldn't we
>>> change it to use Python 3 in preference to Python 2, given that we've
>>> documented py2 as no longer supported?
>>
>> Did we actually document that? My impression was that we want to support
>> both.
>>
> The documentation <https://subversion.apache.org/docs/release-notes/1.14#python2>
> reads:
>
> """This means that although Subversion 1.14.0 still technically works
> with Python 2.7, any later 1.14.x point release may drop this
> support if it becomes too difficult to maintain."""
>
I remember now.
>> It would make sense to prefer Python3 over Python2 by default if both
>> are available, but I wouldn't go further than that. The order of
>> executable names should be [python3, python, python2], IIUC the naming
>> conventions.
> Sounds good to me.
>
> If we make this change, should we roll an rc3 for it?
It's a pure build script change, but it's always nice to be able to
essentially rename the RC to the release (except for svn_version.h
changes). I don't think we have to restart the soak, though.
> Otherwise, if we
> in fact pull py2.7 support at some point (as the release notes allow us
> to), we'd find ourselves having to bump a dependency's major version in
> a patch release.
True.
-- Brane
Re: py2.7 used by default when py2 and py3 are both available
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Fri, 15 May 2020 18:14 +00:00:
> On 15.05.2020 19:19, Daniel Shahaf wrote:
> > I just noticed that when I ran «make check» on trunk, it was run using
> > python 2.7. I hadn't pass any Python-related flags to autogen.sh/configure.
> >
> > I presume py2.7 was used because build/find_python.sh used whatever the
> > "python" executable in my $PATH is.
> >
> > Looking at find_python.sh, that's exactly what it does. Shouldn't we
> > change it to use Python 3 in preference to Python 2, given that we've
> > documented py2 as no longer supported?
>
>
> Did we actually document that? My impression was that we want to support
> both.
>
The documentation <https://subversion.apache.org/docs/release-notes/1.14#python2>
reads:
"""This means that although Subversion 1.14.0 still technically works
with Python 2.7, any later 1.14.x point release may drop this
support if it becomes too difficult to maintain."""
> It would make sense to prefer Python3 over Python2 by default if both
> are available, but I wouldn't go further than that. The order of
> executable names should be [python3, python, python2], IIUC the naming
> conventions.
Sounds good to me.
If we make this change, should we roll an rc3 for it? Otherwise, if we
in fact pull py2.7 support at some point (as the release notes allow us
to), we'd find ourselves having to bump a dependency's major version in
a patch release.
Cheers,
Daniel
Re: py2.7 used by default when py2 and py3 are both available
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, May 15, 2020 at 2:14 PM Branko Čibej <br...@apache.org> wrote:
> On 15.05.2020 19:19, Daniel Shahaf wrote:
> > Looking at find_python.sh, that's exactly what it does. Shouldn't we
> > change it to use Python 3 in preference to Python 2, given that we've
> > documented py2 as no longer supported?
>
>
> Did we actually document that? My impression was that we want to support
> both.
Sort of.
We documented in the 1.14 release notes that Python 2 is being phased out.
The idea being, it works (for now) and we'll try to keep it that way,
but because
the life of 1.14 extends so far past Py2 EOL, any later 1.14.x could drop
that support if it becomes too difficult to maintain. (Suppose no SVN dev
has a working Py2 install because our OSes no longer package it, for
example.)
Nathan
Re: py2.7 used by default when py2 and py3 are both available
Posted by Branko Čibej <br...@apache.org>.
On 15.05.2020 19:19, Daniel Shahaf wrote:
> I just noticed that when I ran «make check» on trunk, it was run using
> python 2.7. I hadn't pass any Python-related flags to autogen.sh/configure.
>
> I presume py2.7 was used because build/find_python.sh used whatever the
> "python" executable in my $PATH is.
>
> Looking at find_python.sh, that's exactly what it does. Shouldn't we
> change it to use Python 3 in preference to Python 2, given that we've
> documented py2 as no longer supported?
Did we actually document that? My impression was that we want to support
both.
It would make sense to prefer Python3 over Python2 by default if both
are available, but I wouldn't go further than that. The order of
executable names should be [python3, python, python2], IIUC the naming
conventions.
-- Brane