guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Merging the purge-python2-packages branch


From: Maxim Cournoyer
Subject: Re: Merging the purge-python2-packages branch
Date: Tue, 31 May 2022 15:07:19 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux)

Hi Simon,

zimoun <zimon.toutoune@gmail.com> writes:

[...]

> BTW, ’python2-biopython’ is broken in the branch
> ’purge-python2-packages’ and still there [1].
>
> 1: <http://ci.guix.gnu.org/build/827139/details>

Thanks.  It's now gone along pplacer-scripts and pplacer, which were
using it as an input.

>> This effort is an attempt to reduce our dependencies on Python 2 as much
>> as possible, so that we can hopefully remove Python 2 from our tree
>> before 2030 comes ;-).
>
> I agree and I am advocating since 2019-10-31 [2] for an explicit
> plan. :-) However, my understanding of this plan after several
> discussions is: remove the python2- variants once they are broken.
>
> It appears to me surprising: we do not provide a schedule for the
> removals, then bang purge.

I think we already had reached consensus that Python 2 packages needed
to go, but the benefit/effort ratio was rather low, so the more
practical alternative to a purge was removing them gradually.  The
ability to use a script [0] to automate a good part of it is what
convinced me otherwise.  Getting entangled in trying to preserve Python
2 packages that few still use when bumping Python packages is another
pain point that made me want to expedite the move.

[0]  
https://git.sr.ht/~apteryx/guix-api-examples/tree/main/item/purge-python2-packages.scm


> 2: 
> <https://yhetil.org/guix/CAJ3okZ33HsXxgVgK3XyVHvYUfDUrbcwBnOn7FC6=3AG_YvAUbQ@mail.gmail.com>
>
>
> Well, as a hobbyist, I am fine with such purge.  As a scientific
> practitioner using Guix at work, it is more annoying…

Agreed.  My understanding is that scientists making use of Guix already
use a variety of Guix channels, so I'd assume the now missing bits can
be fitted in Guix-Past or a suitable place without causing too much of a
change to their workflow.

[...]

> Other said, I am fine with the purge and I volunteer to help in
> transferring from master to guix-past but we need a schedule,
> communicate on the purge and more importantly say when it will
> happen. :-) (maybe not a purge 2-3 days after an announcement on
> guix-devel following 2 weeks in a branch ;-))

To be clear, the whole patch set was submitted for review more than 2
weeks ago to guix-patches, and some people have at least looked at it
and suggested using forks or other means to save some packages, which
was done.  If it breaks something, users can stay on their current
commit, use inferiors, or start integrating the missing bits into their
channel.

So, I'll go ahead with the merge and we can go from there.  In the
future, I'll try to remember to send a guix-devel message around the
time the patches hit guix-patches :-).

Thanks for sharing your input,

Maxim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]