Re: Merging the purge-python2-packages branch

[Ludovic Courtès]

Hello!

zimoun  skribis:

> Again, I agree with the purge, I disagree with the process.

OK, understood.

> Maybe my ideal world is wrong, but to me, the collective process would
> have somehow been on Guix side: patches, branch and CI, announce on
> guix-devel, announce on info-guix and publish a blog post (because the
> script is unique, awesome and really worth), then done.  In my ideal
> world, we were at the announce on guix-devel step.  Hence my surprise.

Yeah.  The patch series had been on issues.guix for two weeks, but
that’s not enough for people to notice; I agree that an announcement at
least on guix-devel, followed by some time to adjust, would have allowed
for a smoother transition.

> It is really interesting: so much care about “guix environment” to avoid
> any breakage of any workflow vs a massive purge without even an announce
> on guix-devel: be aware, many Python 2 will be dropped on .

‘guix environment’ and Python 2 are two different beasts, but you’re
right that the difference in how we handled these two transitions is
striking.

> It is a bit more than pasting; whatever. :-)

Heh, of course, and you’re right to a much larger extent than I thought:
Ricardo and I have been trying to rescue python2-{scipy,numpy} in
Guix-Past and it’s much more difficult than I expected.

>> In the end, it can have a good side effect: getting scientists aware of,
>> and ideally involved in, the maintenance of their own infrastructure.
>> Maybe you have an argument to recruit an new engineer on your team?  :-)
>
> Too much optimism? :-)
>
> To be honest, I get two kind of feedback:
>
>  1. from scientists end-user, a) they do not have the packages they need
>  when these packages are easily available elsewhere, b) many tiny
>  annoyances which do not make daily usage smooth compared to others;
>
>  2. from “sysadmin”, Guix is not enough stable and not ready for production.
>
> Both are not technical but are most about perception. I will not drift
> off topic. ;-)

Yup, I hear that, and I agree that every such annoyance plays against
the project (inaction would also play against it though, only in a more
diffuse way.)

> About “my team”, do you mean recruit myself?  Even, I am probably the
> only potential recruit in my complete Institute. ;-)

What I meant is that scientists cannot always be freeriders, to put it
bluntly.  If we’re providing valuable infrastructure to them, it makes
sense to invest in it—as opposed to identifying as “end users”.

Thanks,
Ludo’.

Re: Merging the purge-python2-packages branch

[Maxime Devos]

zimoun schreef op do 02-06-2022 om 09:25 [+0200]:
> On Wed, 01 Jun 2022 at 22:30, Maxime Devos  wrote:
> 
> > > (from [0])
> > > Sunsetting Python 2
> > > [...]
> > > We did not want to hurt the people using Python 2. So, in 2008, we
> > > announced that we would sunset Python 2 in 2015,
> > 
> > This is a 5 year grace period, which is already a lot of weeks.
> > Futhermore, this has even been extended for five additional years:
> 
> Following this argument, the question is therefore: why Python 2
> packages had been included in Guix in the first place since most
> inclusions had already been post this grace period? :-)

I didn't know that.  I guess we should have said back then ‘no adding
new python2 packages because of the grace period, only updates’ and
announced and documented the policy? (assuming this argument)

> I personally do not follow all the upstream code that I run.  I trust
> the distro for that.  I guess most people follow distro news for most
> of the things they basically run and install from their disto. [...]
> By doing sudden transition, we appear abrupt as a distro and the
> message between the lines is «Guix is not reliable as a distro».  All
> such big transition is difficult whatever the distro [1,2,3].  The
> aim of a distro is to smooth user transition, IMHO, which means
> communicate explicitly for preparing.

I agree that it is a sudden transition for a user that does not follow
upstream news and that it only is a smooth transition for people in the
know.  It's a bit a matter of perspective I guess?  Agreed with more
explicit communication.  And maybe Guix could have done more, e.g. by
helping upstream with porting to python3.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Merging the purge-python2-packages branch

[zimoun]

On Wed, 01 Jun 2022 at 22:30, Maxime Devos  wrote:

>> (from [0])
>> Sunsetting Python 2
>> [...]
>> We did not want to hurt the people using Python 2. So, in 2008, we
>> announced that we would sunset Python 2 in 2015,
>
> This is a 5 year grace period, which is already a lot of weeks.
> Futhermore, this has even been extended for five additional years:

Following this argument, the question is therefore: why Python 2
packages had been included in Guix in the first place since most
inclusions had already been post this grace period? :-)


> That said, I suppose it would have been better to also repeat the
> message about the grace period on the blog, channel news and info-guix
> (and maybe on IRC too, why not) as you seem to suggest, for people that
> follow distro news but not upstream news, given the large impact (many
> python2 packages)?

I personally do not follow all the upstream code that I run.  I trust
the distro for that.  I guess most people follow distro news for most of
the things they basically run and install from their disto.  I would be
interested to know how many people who use pandoc also follow GHC
development, who use unison and also follow OCaml, who use VLC and
follow GCC, etc. Who used ’wicd’ and also followed Python.

Well, it is off-topic. :-)

To be honest, I am also surprised by the answers trying to justify what
appears to me a breakage of what a distro means.  Maybe my feelings are
wrong, from my point of view, Guix is currently at a crossroad: people
outside the hobbyist’s circle are starting to run Guix in production, or
at least they are starting to think about it.  By doing sudden
transition, we appear abrupt as a distro and the message between the
lines is «Guix is not reliable as a distro».  All such big transition is
difficult whatever the distro [1,2,3].  The aim of a distro is to smooth
user transition, IMHO, which means communicate explicitly for preparing.

Do not take me wrong, I am not making a case for this Python 2 purge.

Now, many Python 2 is gone from Guix.  Despite my concerns, I am really
happy by this achievement and I am very grateful to Maxim for making it
happen.  For having done some janitor tasks in Guix, I know how tedious
this job can be and I am thankful for the heavy and not-fun work that
Maxim did.

In short, I have an opinion for the path at this crossroad and using
this Python 2 purge as example, I am trying to gently express it.


Cheers,
simon

1: 
2: 
3: 

Re: Merging the purge-python2-packages branch

[Maxime Devos]

zimoun schreef op wo 01-06-2022 om 21:51 [+0200]:
> Any user of Guix, scientist or not, can be surprised that their
> perfectly working packages are suddenly removed without a period of
> grace.  Yes, these packages could have been removed before today since
> they are EOL since 2 years.  It does not change my concern.
> 
> What is the emergency in the maintenance burden that we cannot publicly
> announce the purge and wait a grace* period?  For the broken packages, I
> understand.  I am sorry but I am still missing for the perfectly working
> packages.
> [...]
> *grace period: it could have been short as couple of weeks.

The grace period has been started back in 2008 and ended in 2015.
I don't know the original location where this has been publicly
announced, but there is [0]:

> (from [0])
> Sunsetting Python 2
> [...]
> We did not want to hurt the people using Python 2. So, in 2008, we
> announced that we would sunset Python 2 in 2015,

This is a 5 year grace period, which is already a lot of weeks.
Futhermore, this has even been extended for five additional years:

> (from [0])
> and asked people to upgrade before then. Some did, but many did not.
> So, in 2014, we extended that sunset till 2020

So we're at a ten-year grace period.  And some distros have informally
extended the grace period a bit longer to some limited degree.

That said, I suppose it would have been better to also repeat the
message about the grace period on the blog, channel news and info-guix
(and maybe on IRC too, why not) as you seem to suggest, for people that
follow distro news but not upstream news, given the large impact (many
python2 packages)?

[0]: https://www.python.org/doc/sunset-python-2/

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Merging the purge-python2-packages branch

[zimoun]

Hi,

On Wed, 01 Jun 2022 at 18:21, Ludovic Courtès  wrote:

> The question boils down to: how can we maintain a general-purpose
> package collection?

I agree and I never said that we have to maintain packages EOL since 2
years.

As I pointed, many packages of these set are not broken… yet.

Any user of Guix, scientist or not, can be surprised that their
perfectly working packages are suddenly removed without a period of
grace.  Yes, these packages could have been removed before today since
they are EOL since 2 years.  It does not change my concern.

What is the emergency in the maintenance burden that we cannot publicly
announce the purge and wait a grace* period?  For the broken packages, I
understand.  I am sorry but I am still missing for the perfectly working
packages.

Again, I agree with the purge, I disagree with the process.

*grace period: it could have been short as couple of weeks.


> It’s great that you’re voicing the concerns of the scientific community.
> At the end of the day though, someone has to maintain all this code.
> We’re removing packages from Guix proper, letting interested users
> either pin their software environment or maintain those packages in a
> channel of their own.  In the latter case, the maintenance burden is
> transferred.

My concern is mainly about the process, not the purge.  As you can read
in the Git log, I have removed many broken Python 2 packages.  And as
you can also read in the mailing list archive, I have been concerned by
this topic and I tried to propose (many times) a plan for a smooth
transition because package removals.

Maybe I am wrong but I see a difference in a transition plan between
collectively maintain all this code for 2 years and remove many working
packages without a public announce.

I agree with the purge and it is nice that it happens.  But I am
surprised by the abrupt process.  A grace period could have smoothed the
transition for the few interested users, if any. :-)

Maybe my ideal world is wrong, but to me, the collective process would
have somehow been on Guix side: patches, branch and CI, announce on
guix-devel, announce on info-guix and publish a blog post (because the
script is unique, awesome and really worth), then done.  In my ideal
world, we were at the announce on guix-devel step.  Hence my surprise.


> The transition can be difficult; surely, some user out there will
> discover all of a sudden that their favorite package disappeared.  As
> engineers who support scientific users, you and I (and others) can help
> smooth that by pasting package definitions that we know are still used
> into Guix-Past or some other channels.

It is a bit more than pasting; whatever. :-)

It is really interesting: so much care about “guix environment” to avoid
any breakage of any workflow vs a massive purge without even an announce
on guix-devel: be aware, many Python 2 will be dropped on .
Anyway.

As I said, I am surprised.  But the world is not exploding. :-) Come on,
it is Python 2 EOL since 2 years!

Even, I am very grateful that this boring janitor task of purging is
almost done.  Many thanks to Maxim for the hard and not fun work!

The script and various tools around are really great materials exposing
how Guix is powerful.  Awesome and thanks!


> In the end, it can have a good side effect: getting scientists aware of,
> and ideally involved in, the maintenance of their own infrastructure.
> Maybe you have an argument to recruit an new engineer on your team?  :-)

Too much optimism? :-)

To be honest, I get two kind of feedback:

 1. from scientists end-user, a) they do not have the packages they need
 when these packages are easily available elsewhere, b) many tiny
 annoyances which do not make daily usage smooth compared to others;

 2. from “sysadmin”, Guix is not enough stable and not ready for production.

Both are not technical but are most about perception. I will not drift
off topic. ;-)

About “my team”, do you mean recruit myself?  Even, I am probably the
only potential recruit in my complete Institute. ;-)


Bah yeah optimism!  I am surprised and surprised are often fun! :-)


Cheers,
simon

Re: Merging the purge-python2-packages branch

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Tue, 31 May 2022 at 15:07, Maxim Cournoyer  
> wrote:
>
>>> 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.
>
> This assumption about scientists is not rooted, IMHO.  What I can say is
> that, in my lab, some people are still using python2- variants as ’bamm’
> for example.  They are not packager and they have other fishes to fry;
> they use Guix to have the things done, they are not hobbyists who like
> tweaking their computational environment. :-)

I’m sure you’re right.

The question boils down to: how can we maintain a general-purpose
package collection?

It’s great that you’re voicing the concerns of the scientific community.
At the end of the day though, someone has to maintain all this code.
We’re removing packages from Guix proper, letting interested users
either pin their software environment or maintain those packages in a
channel of their own.  In the latter case, the maintenance burden is
transferred.

The transition can be difficult; surely, some user out there will
discover all of a sudden that their favorite package disappeared.  As
engineers who support scientific users, you and I (and others) can help
smooth that by pasting package definitions that we know are still used
into Guix-Past or some other channels.

In the end, it can have a good side effect: getting scientists aware of,
and ideally involved in, the maintenance of their own infrastructure.
Maybe you have an argument to recruit an new engineer on your team?  :-)

Ludo’.

Re: Merging the purge-python2-packages branch

[zimoun]

Hi Maxim,

Thanks for this janitor work. :-)


On Tue, 31 May 2022 at 15:07, Maxim Cournoyer  wrote:

>> 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.

This assumption about scientists is not rooted, IMHO.  What I can say is
that, in my lab, some people are still using python2- variants as ’bamm’
for example.  They are not packager and they have other fishes to fry;
they use Guix to have the things done, they are not hobbyists who like
tweaking their computational environment. :-)

If I do not transfer myself the packages or explain them how to reach
these packages (git log, find the commit, etc. because yes, some people
are still installing python2- variants for some specific tasks), then
they will probably have again another bad experience with Guix.

And no, 15 days is not enough time to move 602 packages (minus the
broken ones ;-)) from master to another channel as guix-past.

Some workflow will be broken, for sure.  Bah it is an habits when using
Guix, sadly. :-)


> 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 :-).

Again, I totally agree with the purge.  But I disagree with the process.

Somehow, it is another data point showing it is hard to smoothly work in
production with Guix – some flavors are moving too fast for my taste [1].

Anyway!  The merge will be a double “darwinism” experience. ;-) Only the
most motivated* users with a broken workflow will accept such breakage.
Only the most relevant python2- variant packages will survive
elsewhere. :-)

*darwinism meaning here “selection”
*motivated by other unique Guix features

1: 


Cheers,
simon

Re: Merging the purge-python2-packages branch

[Maxim Cournoyer]

Hi Simon,

zimoun  writes:

[...]

> BTW, ’python2-biopython’ is broken in the branch
> ’purge-python2-packages’ and still there [1].
>
> 1: 

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: 
> 
>
>
> 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

Re: Merging the purge-python2-packages branch

[Reza Housseini]

On 5/30/22 18:49, zimoun wrote:


 Well, me, personally, I continue to do most of my research using
 Python 2 because I cannot afford to port everything to Python
 3. And since I do only number crunching, meaning nothing with
 security implications, I am not particularly worried.

 [...]

 Once Python 2 lives in a largely isolated package sub-universe,
 I don't see much harm keeping it in Guix for now. If security
 issues become apparent, we might have to do something more
 drastic.


I think time-machine is the tool to use here, and as Maxime suggested, 
if you really need to keep maintaining a python2 package than guix-past 
is the perfect place to do it (porting to python3 makes probably still 
more sense than maintaining an outdated python package).




It appears to me surprising: we do not provide a schedule for the
removals, then bang purge.



I don't see the problem, python 2 was sunsetting in 2020(!) [1] after a 
prolongation from 2015, so it should not come as a surprise.


Cheers,
Reza


[1] https://www.python.org/doc/sunset-python-2/

--
Reza Housseini

This message is signed with my GnuPG key:

C0F3 0812 9AF2 80F4 0830 C2C1 C375 C6AF 0512 5C52


OpenPGP_0xC375C6AF05125C52.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Merging the purge-python2-packages branch

[zimoun]

Hi Maxim,

On lun., 30 mai 2022 at 11:32, Maxim Cournoyer  
wrote:
> zimoun  writes:
>> On lun., 30 mai 2022 at 09:25, Maxim Cournoyer  
>> wrote:
>>
>>> Most of the removal were automated using a script [0], but each package
>>> removed had their upstream status considered (using last commit or
>>> existing patches for Python 3 compatibility) and quite a few were saved
>>> that way.
>>
>> These packages perfectly build.
>
> On Python 2, that is :-).

Yeah. :-)  Another point of view:

Well, me, personally, I continue to do most of my research using
Python 2 because I cannot afford to port everything to Python
3. And since I do only number crunching, meaning nothing with
security implications, I am not particularly worried.

[...]

Once Python 2 lives in a largely isolated package sub-universe,
I don't see much harm keeping it in Guix for now. If security
issues become apparent, we might have to do something more
drastic.




And if you filter by ’python2-’ from the dashboard,



many are broken but many are still fine.

BTW, ’python2-biopython’ is broken in the branch
’purge-python2-packages’ and still there [1].

1: 


> 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.

2: 



Well, as a hobbyist, I am fine with such purge.  As a scientific
practitioner using Guix at work, it is more annoying…

>> bamm /gnu/store/17hs9c60isdk8sfkpi0280xzc0gkyxn1-bamm-1.7.3

[...]

>> Therefore, I would not remove them; I have not checked which python2-
>> dependencies they are using.
>
> If something is valuable up there, I'd suggest interested parties
> contribute them to the Guix-Past channel.

…for instance, I use time to time the package ’bamm’.  Because inferiors
and time-machine, the removal of ’bamm’ is not a big deal per se but I
need some time to adapt some scripts, etc.

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 ;-))


Cheers,
simon

PS: Great script, BTW. :-)

Re: Merging the purge-python2-packages branch

[Maxim Cournoyer]

Hi Simon,

zimoun  writes:

> Hi Maxim,
>
> Cool!  That’s a nice removal. :-)
>
> On lun., 30 mai 2022 at 09:25, Maxim Cournoyer  
> wrote:
>
>> Most of the removal were automated using a script [0], but each package
>> removed had their upstream status considered (using last commit or
>> existing patches for Python 3 compatibility) and quite a few were saved
>> that way.
>
> These packages perfectly build.

On Python 2, that is :-).

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 ;-).

> bamm /gnu/store/17hs9c60isdk8sfkpi0280xzc0gkyxn1-bamm-1.7.3
> childsplay   /gnu/store/1gjbfx4s30r074fl1nhr5m8srsxvmavf-childsplay-3.4
> chirp/gnu/store/piwqmj7y6b1b3p0sk9vxwzd3fn68nz00-chirp-20220118
> djvusmooth   /gnu/store/y1djnpg169mm51381ylrjxdrxa8la3xa-djvusmooth-0.3
> find-circ
> /gnu/store/i1vbr24h858irfwlnldjb2brsrl7j168-find-circ-1.2-1.8655dca
> fraggenescan /gnu/store/h211d2xqsf1dcqhm9b9mp4dl463hslxn-fraggenescan-1.30
> gnome-doc-utils  
> /gnu/store/z6kwlmqyrfrpmvh75sz109krlk5jk9i3-gnome-doc-utils-0.20.10
> graphios /gnu/store/38fk6qkqvcjl7q63j8iasqb4igr715jf-graphios-2.0.3
> gtklick  /gnu/store/zdh104pc78camqk96dy23yp61xq0695h-gtklick-0.6.4
> h-client 
> /gnu/store/z8cg927pfl318ds0aifx7s9q4mxkvzgl-h-client-0.0a0-138
> ingen
> /gnu/store/xhxg7q3g5zffx8qpkcnz8h4wp6jwqg9r-ingen-0.0.0-2.cc4a4db33
> key-mon  /gnu/store/y6fq6plq1v2myl8nszhp06c9xr8bcfli-key-mon-1.17
> lekha/gnu/store/akcbq03r9n6ap6p781c18n5xllid5y8s-lekha-0.2.1
> mloop
> /gnu/store/v94mbqhji8ag0v12v00zq9nd5b6lgirq-mloop-0.0.1-0.adebff9
> non-mixer
> /gnu/store/cmm8drl9isnmcgrzlsv9mrqrvknwchfm-non-mixer-1.9.5-4.5ae43bb
> non-timeline 
> /gnu/store/kazn7qihs8q3b4qmi6md7y0dk5ivhv7s-non-timeline-1.9.5-4.5ae43bb
> omnitux  /gnu/store/qbpsz7zaxdpaicmdxvp6s086yqplh4ks-omnitux-1.2.1
> patches  
> /gnu/store/5qvzzri85wiph03kcpknvg0kpnwj528g-patches-0.0-1.ef1b8a7
> pyicoteo /gnu/store/vcrdrgzvgfbv28k9qj291jx8r31m7l1j-pyicoteo-2.0.7
> raul 
> /gnu/store/6l5960xcmdggfkrsnnll5pb72knj2dga-raul-0.8.9-1.4db870b2b
> rawdog   /gnu/store/vbw20xafk84p34y56bgjcbhnz2fvshnm-rawdog-2.23
> sala /gnu/store/c5s2ig87xq4ld7fvx0z1adk8hjgvqkds-sala-1.3
> slingshot/gnu/store/ck765xq1izagvb14bvj6vkaarlam88c0-slingshot-0.9
> wicd /gnu/store/rmg0f4qx7ac3w148cxigmj9xkdzzwa6d-wicd-1.7.4
> youtube-dl-gui   
> /gnu/store/lgf9xbfi7rp91kbajbxirbndssfgfwvw-youtube-dl-gui-0.4
>
> Therefore, I would not remove them; I have not checked which python2-
> dependencies they are using.

If something is valuable up there, I'd suggest interested parties
contribute them to the Guix-Past channel.

What do you think?

Maxim

Re: Merging the purge-python2-packages branch

[zimoun]

Hi Maxim,

Cool!  That’s a nice removal. :-)

On lun., 30 mai 2022 at 09:25, Maxim Cournoyer  
wrote:

> Most of the removal were automated using a script [0], but each package
> removed had their upstream status considered (using last commit or
> existing patches for Python 3 compatibility) and quite a few were saved
> that way.

These packages perfectly build.

--8<---cut here---start->8---
bamm /gnu/store/17hs9c60isdk8sfkpi0280xzc0gkyxn1-bamm-1.7.3
childsplay   /gnu/store/1gjbfx4s30r074fl1nhr5m8srsxvmavf-childsplay-3.4
chirp/gnu/store/piwqmj7y6b1b3p0sk9vxwzd3fn68nz00-chirp-20220118
djvusmooth   /gnu/store/y1djnpg169mm51381ylrjxdrxa8la3xa-djvusmooth-0.3
find-circ
/gnu/store/i1vbr24h858irfwlnldjb2brsrl7j168-find-circ-1.2-1.8655dca
fraggenescan /gnu/store/h211d2xqsf1dcqhm9b9mp4dl463hslxn-fraggenescan-1.30
gnome-doc-utils  
/gnu/store/z6kwlmqyrfrpmvh75sz109krlk5jk9i3-gnome-doc-utils-0.20.10
graphios /gnu/store/38fk6qkqvcjl7q63j8iasqb4igr715jf-graphios-2.0.3
gtklick  /gnu/store/zdh104pc78camqk96dy23yp61xq0695h-gtklick-0.6.4
h-client /gnu/store/z8cg927pfl318ds0aifx7s9q4mxkvzgl-h-client-0.0a0-138
ingen
/gnu/store/xhxg7q3g5zffx8qpkcnz8h4wp6jwqg9r-ingen-0.0.0-2.cc4a4db33
key-mon  /gnu/store/y6fq6plq1v2myl8nszhp06c9xr8bcfli-key-mon-1.17
lekha/gnu/store/akcbq03r9n6ap6p781c18n5xllid5y8s-lekha-0.2.1
mloop
/gnu/store/v94mbqhji8ag0v12v00zq9nd5b6lgirq-mloop-0.0.1-0.adebff9
non-mixer
/gnu/store/cmm8drl9isnmcgrzlsv9mrqrvknwchfm-non-mixer-1.9.5-4.5ae43bb
non-timeline 
/gnu/store/kazn7qihs8q3b4qmi6md7y0dk5ivhv7s-non-timeline-1.9.5-4.5ae43bb
omnitux  /gnu/store/qbpsz7zaxdpaicmdxvp6s086yqplh4ks-omnitux-1.2.1
patches  
/gnu/store/5qvzzri85wiph03kcpknvg0kpnwj528g-patches-0.0-1.ef1b8a7
pyicoteo /gnu/store/vcrdrgzvgfbv28k9qj291jx8r31m7l1j-pyicoteo-2.0.7
raul 
/gnu/store/6l5960xcmdggfkrsnnll5pb72knj2dga-raul-0.8.9-1.4db870b2b
rawdog   /gnu/store/vbw20xafk84p34y56bgjcbhnz2fvshnm-rawdog-2.23
sala /gnu/store/c5s2ig87xq4ld7fvx0z1adk8hjgvqkds-sala-1.3
slingshot/gnu/store/ck765xq1izagvb14bvj6vkaarlam88c0-slingshot-0.9
wicd /gnu/store/rmg0f4qx7ac3w148cxigmj9xkdzzwa6d-wicd-1.7.4
youtube-dl-gui   /gnu/store/lgf9xbfi7rp91kbajbxirbndssfgfwvw-youtube-dl-gui-0.4
--8<---cut here---end--->8---

Therefore, I would not remove them; I have not checked which python2-
dependencies they are using.


Cheers,
simon

Merging the purge-python2-packages branch

[Maxim Cournoyer]

Hi everyone,

Just so you know, there's this 'purge-python2-packages' branch that does
away with quite a few Python 2 packages.  It greatly reduces the Python
2 dependency graph of Python 2 packages, without totally eliminating it
yet.

Here's the list of removed packages, obtained with

"git log origin/purge-python2-packages...origin/master --oneline --grep='gnu: 
Remove'"

--8<---cut here---start->8---
bcb9b1689f gnu: Remove python2-pytest-cov.
426e945a3e gnu: Remove python2-called-python.
4963a61644 gnu: Remove python-prompt-toolkit-2.
39ca4b0895 gnu: Remove python2-setuptools.
42b923915b gnu: Remove python2-checkm-genome.
2b25c71b1c gnu: Remove python2-backports-csv.
ddde4dedff gnu: Remove python2-fonttools.
63445163fa gnu: Remove python2-py.
ee4f035c2c gnu: Remove python2-pyparsing.
633b0846dd gnu: Remove python2-setuptools-scm.
799022b040 gnu: Remove python2-six-bootstrap.
473c00f17e gnu: Remove python2-pyxdg.
c652b8ce97 gnu: Remove python2-wcwidth.
f528943a13 gnu: Remove python2-pyyaml.
b68c90e347 gnu: Remove python2-nose.
43f57f04ff gnu: Remove python2-attrs-bootstrap.
8102195b97 gnu: Remove python2-libxml2.
90b63ad7a6 gnu: Remove 4store.
2c51888c32 gnu: Remove python2-pyfakefs-bootstrap.
ea7af59a5e gnu: Remove python2-cython.
6b3c3c383d gnu: Remove python2-lirc.
c7abbbf24c gnu: Remove python2-tlsh.
c4fd72dc2f gnu: Remove python2-more-itertools.
e7dafd7fdb gnu: Remove gnome-doc-utils.
ae2cd32bf4 gnu: Remove python2-libmpsse.
d256f68b1a gnu: Remove python2-lxml.
f90acf5982 gnu: Remove vtk-6.
021daaae36 gnu: Remove python2-appdirs.
87382d2c97 gnu: Remove python2-enum34.
cd97147785 gnu: Remove boost-with-python2.
82655b3665 gnu: Remove libpng-1.2.
9c83be6d09 gnu: Remove rapicorn.
f7f51c8aa5 gnu: Remove beast.
64d7097f72 gnu: Remove python2-linecache2.
403c9a8bd6 gnu: Remove python2-traceback2.
f26e596977 gnu: Remove python2-unittest2.
8edc2ca792 gnu: Remove python2-sortedcontainers.
280160e6fe gnu: Remove python2-funcsigs.
9864dd74e6 gnu: Remove python2-functools32.
8bea025529 gnu: Remove python2-hypothesis.
2500d57fe8 gnu: Remove python2-mock.
8dcbf523e8 gnu: Remove python2-pysqlite.
ad11abe73a gnu: Remove fraggenescan.
001dcfe351 gnu: Remove python2-olefile.
f313590b9c gnu: Remove python2-pillow.
46c19049ce gnu: Remove python2-seaborn.
c94cc00653 gnu: Remove python2-iso8601.
cec9ad5412 gnu: Remove python2-pytz.
9923879424 gnu: Remove python2-pretend.
0f3106740f gnu: Remove python2-idna.
60999d1cec gnu: Remove python2-backport-ssl-match-hostname.
f90fcfa33d gnu: Remove python2-scandir.
067338674a gnu: Remove python2-ipaddress.
ecde6fb0f3 gnu: Remove python2-asn1crypto.
acc9331f64 gnu: Remove python2-cryptography-vectors.
d6e92d91e4 gnu: Remove python2-cffi.
80cd6bd92b gnu: Remove python2-coverage.
34632df3ad gnu: Remove python2-dateutil.
4288a209a0 gnu: Remove python2-contextlib2.
a9352dfd8c gnu: Remove python2-typing.
4553ce8c44 gnu: Remove python2-pathlib2.
f31fe6b464 gnu: Remove python2-cryptography.
8c271b7b36 gnu: Remove python2-flaky.
1b11565908 gnu: Remove python2-backports-functools-lru-cache.
806dee732c gnu: Remove python2-pysocks.
15f7284ca1 gnu: Remove python2-importlib-resources.
37e6c0cce1 gnu: Remove python2-configparser.
ff7906505e gnu: Remove python2-unidecode.
2e1f0db2ef gnu: Remove python2-pyopenssl.
5a553edb4b gnu: Remove python2-certifi.
45bb3af633 gnu: Remove python2-zipp.
1762727626 gnu: Remove python2-packaging-bootstrap.
e0d0dda357 gnu: Remove python2-freezegun.
01fbe51039 gnu: Remove python2-wxpython.
c4eecc10bb gnu: Remove python2-sphinxcontrib-websupport.
3c2fce40af gnu: Remove python2-sphinx-alabaster-theme.
80e4e36445 gnu: Remove python2-pyicu.
d63d7f941a gnu: Remove python2-importlib-metadata.
7736e3b727 gnu: Remove python2-atomicwrites.
1fa434063f gnu: Remove python2-soupsieve.
7e6555826e gnu: Remove python2-pylev.
4ea894581c gnu: Remove python2-simplejson.
c2c6b933bc gnu: Remove python2-pyaml.
803f6252e4 gnu: Remove python2-levenshtein.
2f5ca3eb6f gnu: Remove python2-babel.
fbe609158c gnu: Remove python2-imagesize.
3624fd07d4 gnu: Remove python2-chardet.
1fe6e8fe45 gnu: Remove python2-markupsafe.
1484188321 gnu: Remove python2-urllib3.
e4acbdffcb gnu: Remove python2-webencodings.
315b565c1e gnu: Remove python2-pastel.
8ce7494431 gnu: Remove python2-vobject.
0dc76a6463 gnu: Remove python2-twodict.
1f82af14b5 gnu: Remove python2-jinja2.
df863c18f5 gnu: Remove python2-diff-match-patch.
64c7814b47 gnu: Remove python2-urwid.
a37c26a173 gnu: Remove python2-backpack.
bc30e08839 gnu: Remove python2-packaging.
08216338a6 gnu: Remove python2-snowballstemmer.
eb77c6aa62 gnu: Remove python2-funcsigs-bootstrap.
56e84700e2 gnu: Remove python2-clikit.
32b1f9f190 gnu: Remove python2-beautifulsoup4.
fa9c9305a2 gnu: Remove python2-decorator.
1b34fff0e4 gnu: Remove python2-docopt.
b9a8dd6a5e gnu: Remove python2-bottle.
6870c2c22c gnu: Remove python2-requests.
7387002a45 gnu: Remove python2-zinnia.
76ed5d930b gnu: Remove python2-pycairo.
4dbde1c79e gnu: