Re: Merging the purge-python2-packages branch

["Ludovic Courtès" <ludo@gnu.org>]

Hello!

zimoun <zimon.toutoune@gmail.com> 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 <date>.

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