Finalizing Fedora's Switch to Python 3
by Miro Hrončok
Hello fellow Fedora contributors,
We've created a page on Fedora wiki [1] that's something like a Change
proposal*.
The document is called "Finalizing Fedora's Switch to Python 3" and it
describes steps needed in order to:
* Switch /usr/bin/python to Python 3 in cooperation with Python upstream.
* Switch `dnf install python-foo` to install python3-foo.
* Hopefully eventually get rid of Python 2.
This is all planned to line with the fact that Python 2 will be dead
upstream by 2020.
The first phase of the changes is planned for Fedora 30, which is pretty
far away today, but the proposal involves changing thousands of
packages. Hence we'd like to have something we can use to support our
efforts.
I'd like to gather feedback for the document: whether the changes are
understandable and make sense, whether you think we should do things
differently, etc.
[1] https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3
* It involves steps in multiple releases, so we were advised not to
create a multi-release Change proposal, but instead split it into more.
This page summarizes it all an individual Change proposals will follow.
Thank you,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6 years, 1 month
Re: Finalizing Fedora's Switch to Python 3
by Miro Hrončok
On 28.7.2017 20:11, Colin Walters wrote:
>
>
> On Fri, Jul 28, 2017, at 01:53 PM, Randy Barlow wrote:
>> On Fri, 2017-07-28 at 12:41 -0400, Colin Walters wrote:
>>> I'm opposed to switching the meaning of `/usr/bin/python` for AH
>>> anytime soon. It's just going to break stuff, and to me the gain is
>>> quite
>>> low.
>>
>> One of Fedora's stated goals is to remain close to the upstream.
>> Upstream Python is going to change /usr/bin/python to mean Python 3. If
>> AH keeps it on Python 2, it will be confusing for Python programmers
>> using AH. It will be especially confusing for programmers who want to
>> write software that works on "normal" Fedora and AH.
>
> First, I don't see a need for even mild pejoratives; instead of "normal" you could say
> for example "other editions".
>
> Now, we don't really expect people "program" AH directly in that sense;
> most development should go in containers, except for development of
> the various Python things we carry in the host, but that's not a huge set.
>
>> Also, as software
>> begins to switch AH will have to patch its Python packages, diverging
>> from the rest of Fedora.
>
> That's actually something I hadn't even considered; is it proposed
> here to actually have a flag day where all (or even some) of the python3 executables
> start using /usr/bin/python and everything else is /usr/bin/python2?
No. We'd like to keep it the way that everything in Fedora either uses
/usr/bin/python3 or /usr/bin/python2. To keep the possibility for the
sysadmins to change /usr/bin/python to whatever crazy target they want.
Patching packages would not be required here.
> The scope of that would appear to me to be quite staggering.
>
> Are we really at the point even where everything that's python2 only
> explicitly references /usr/bin/python2? I'm doubtful.
>
>> I don't see a practical advantage to divergence. I believe the
>> divergence will break stuff in a more confusing manner than the change
>> will.
>
> I don't want to break Ansible users or in general random sysadmin scripts;
> the value of replacing the meaning of /usr/bin/python feels quite low relative
> to that.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6 years, 1 month
Re: Finalizing Fedora's Switch to Python 3
by Miro Hrončok
On 28.7.2017 18:41, Colin Walters wrote:
> On Fri, Jul 28, 2017, at 12:16 PM, Miro Hrončok wrote:
>
>> It's up to the maintainers of Atomic Host to decide what's there. I
>> don't see how that relates to this thread. We have never said anything
>> about what is supposed to be or not to be in the Atomic Host.
>
> I'm opposed to switching the meaning of `/usr/bin/python` for AH
> anytime soon. It's just going to break stuff, and to me the gain is quite
> low. If you still propose to make that change for other editions and in the Everything repository,
> we'll likely need to override it.
>
> Regardless, I can certainly take care of updating the Change proposal to mention
> that the `/usr/bin/python` portion doesn't apply to AH, and we'll continue
> to have `python2` installed by default, if that's OK with you?
As long as you figure out how to do it properly and as long as you
represent the AH maintainers and can make that decision for AH, I think
it's probably OK to put it there (I still don't like it personally, but
that's not good enough reason to not do it).
What about this:
Note that after Phase 1, nothing in Fedora uses /usr/bin/python any
more, so it should be safe for sysadmins to flip the symblink back to
python2 and we should provide a documented and supported way of doing
so. In the same way, the Atomic Host will keep /usr/bin/python pointing
to Python 2 regardless of rest of Fedora and possibly against upstream
recommendation in PEP 394, because of [reasons].
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6 years, 1 month
Re: Finalizing Fedora's Switch to Python 3
by Miro Hrončok
On 28.7.2017 17:51, Colin Walters wrote:
>
>
> On Fri, Jul 28, 2017, at 11:34 AM, Miro Hrončok wrote:
>> The change has to
>> start somewhere and even though I cannot really speak about RHEL,
>> I would think that changing it in Fedora first makes more sense.
>
> There hasn't been a single "Fedora" since we landed the editions,
> although that's somewhat superficial. With Modularity there will
> *really* no longer be one "Fedora". Want to drop python2 out of
> the container base image? Actually, that's done already! I'm
> all for that. Anyone who wants python2 in their containers
> is probably going to be choosing centos/rhel anyways.
>
> Dropping python2 from Workstation? Sure, sounds fine to me, I
> don't care much personally. I'm just pushing back against that change
> landing for Atomic Host.
It's up to the maintainers of Atomic Host to decide what's there. I
don't see how that relates to this thread. We have never said anything
about what is supposed to be or not to be in the Atomic Host.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6 years, 1 month
Re: Finalizing Fedora's Switch to Python 3
by Miro Hrončok
On 28.7.2017 16:17, Colin Walters wrote:
>
>
> On Fri, Jul 28, 2017, at 07:47 AM, Peter Robinson wrote:
>> On Fri, Jul 28, 2017 at 11:48 AM, Colin Walters <walters(a)verbum.org> wrote:
>>> On Thu, Jul 27, 2017, at 12:07 PM, Miro Hrončok wrote:
>>>
>>>> * Switch /usr/bin/python to Python 3 in cooperation with Python upstream.
>>>
>>> That again? That really seems like a nonstarter; previous
>>> discussion specifically around Atomic Host + Ansible:
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>>
>> Ansible now supports clients that are py3 only and there's active work
>> [1] to enable py3 for the controller as well.
>
> Yes. But basically, I don't think we can rely on everyone porting their Ansible
> code to Python3 anytime soon. Among other reasons, many, many organizations
> will need their Ansible (and in general, "config mgmt/scripting") to work across
> RHEL7 and Fedora hosts. For Fedora Atomic Host (which may be different from
> Workstation!) I don't see dropping /usr/bin/python as python2 until RHEL7 is
> near EOL. Maybe we don't do security updates for it etc., but still.
If we don't switch it in Fedora until RHEL7 is near EOL, it will neither
be changed in any hypothetical future versions of RHEL, because RHEL
tends to be based on Fedora. And than you can say that we cannot do the
switch in Fedora until that hypothetical future version of RHEL is near
EOL and you will end up never changing it at all. The change has to
start somewhere and even though I cannot really speak about RHEL,
I would think that changing it in Fedora first makes more sense.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6 years, 1 month
Re: Finalizing Fedora's Switch to Python 3
by Miro Hrončok
On 28.7.2017 14:29, Brian Exelbierd wrote:
> On Fri, Jul 28, 2017, at 12:48 PM, Colin Walters wrote:
>> On Thu, Jul 27, 2017, at 12:07 PM, Miro Hrončok wrote:
>>
>>> * Switch /usr/bin/python to Python 3 in cooperation with Python upstream.
>>
>> That again? That really seems like a nonstarter; previous
>> discussion specifically around Atomic Host + Ansible:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>>
>> Plus just breaking everyone's random old scripts. Now, I
>> don't know if this has been discussed upstream
>
> This is a statement born of ignorance, but ...
>
> Would it be possible to switch the default from python2 to python3 and
> provide an RPM that would switch it back? This way people who needed to
> stay on python2 for some time period to clean up legacy components
> before teh 2020 EOL could.
Not yet sure about the actual technical solution here, but we are
planning for this use case, see [1]:
"Note that after Phase 1, nothing in Fedora uses /usr/bin/python any
more, so it should be safe for sysadmins to flip the symblink back to
python2 and we should provide a documented and supported way of doing so."
[1]
https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#Phase_2:_S...
>
> I realize that package renaming and things like that will move forward
> regardless and should.
>
> regards,
>
> bex
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6 years, 1 month
Re: Finalizing Fedora's Switch to Python 3
by Miro Hrončok
On 28.7.2017 12:48, Colin Walters wrote:
> On Thu, Jul 27, 2017, at 12:07 PM, Miro Hrončok wrote:
>
>> * Switch /usr/bin/python to Python 3 in cooperation with Python upstream.
>
> That again?
Seems like a never ending story, right? :(
> That really seems like a nonstarter; previous> discussion
specifically around Atomic Host + Ansible:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>
> Plus just breaking everyone's random old scripts.
Actually, we are trying to avoid that. In the corresponding part of the
document [1], we actually say:
"Note that after Phase 1, nothing in Fedora uses /usr/bin/python any
more, so it should be safe for sysadmins to flip the symblink back to
python2 and we should provide a documented and supported way of doing so."
> Now, I> don't know if this has been discussed upstream,
It is being discussed upstream right now and the discussion is linked
from the relevant part of the document [2][3].
> but one> thing to do possibly would be to have an interactive shell
> alias for `python` = `ipython3` or something like that, and
> switch `ipython` to `ipython3`.
[1]
https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#Phase_2:_S...
[2]
https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#Interlude:...
[3] https://mail.python.org/pipermail/linux-sig/2017-July/000029.html
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6 years, 1 month
Adjusting the way Fedora runs Python's test suite
by Nick Coghlan
Hi folks,
While working on bootstrapping a new community sclo-python collection,
I ran into some readability problems with the way the SCL Python spec
file runs the test suite: it uses --verbose mode, which means there's
a lot of noisy output to sort through to find the actual failure when
something goes wrong.
Charalompos pointed out that since the SCL spec file is ultimately
derived from the Fedora one, Fedora would be the best place to file an
issue suggesting some changes, which I've now done:
https://bugzilla.redhat.com/show_bug.cgi?id=1473130
The main suggestion there is one that's a clear win: replace the
current "--verbose" with "-wW" instead, so that the tests are run in
non-verbose mode by default, but if one fails, not only will the test
suite print out any captured output, but it will also immediately
rerun the failed test in verbose mode.
However, I also noted some other possibilities that seem worth discussing:
* checking for refleaks means we can't run parallel tests across
multiple processes. If we were to move refleak testing out to an
integration test in Taskotron, then the tests could be run with the
"-j4" option, significantly reducing the time needed to run the %check
step
* the `--failfast` option causes the tests to be aborted as soon as
one fails. While that doesn't make any difference in the success case,
it will mean faster turnaround cycles in the case where one fails. I'm
less sure of the value of this one, as the downside is that if you're
getting multiple failures, you only find out about them one at a time.
* there's a `--slowest` flag in recent releases that lists the 10
slowest tests in a given run. As far as I know, it doesn't add much
overhead to the test execution process, and provides an indicator of
where to focus efforts if the goal is to make the tests more
efficient.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
6 years, 2 months