zimoun <zimon.toutoune@gmail.com> writes:
Toggle quote (2 lines)
> First, have you read the proposal?
Toggle quote (2 lines)
> Or are you (maybe a bit) "overreacting" about the backward compatibility?
I don’t think so. I am definitely reacting strongly, but that’s because
breakages in Guix have already cost me the evenings of several weeks
this year.
But before I write anything more, I’d like to ask you to take a step
back to breathe.
We’re discussing a change in software. We disagree on the way forward,
but I’m not attacking you as a person, and I hope it does not feel that
way to you.
If it does: This is not my intention. Please take a moment to sigh
deeply, shake your head, relax, and smile — because that actually helps.
It’s what I try to do when discussions get vexing.
I am grateful that you’re taking up improvements in Guix, and there are
situations where viewpoints are different. That is OK.
Toggle quote (7 lines)
>> This is taking this a bit too easy. If I can no longer pull, because
>> that breaks my Emacs or Gnome, then Guix is broken for me: I can no
>> longer update my system without first adjusting my config.
>
> So you expect that we would push a patch changing "guix environment"
> and in the same time break "guix pull, isn't it?
No, this is an example which shows that being able to roll back does not
mean that there is no problem with breaking the way forward. Using only
old versions is often not an option. Just imagine running audio software
from 5 years ago on a system that only provides pulseaudio (or whatever
will come after it). Imagine using an old KDE DCOP-based automation
workflow on a dbus-system. You need to update the libraries you use to
get it working at all.
Toggle quote (10 lines)
>> > Hum? I am not convinced that the cost would be high... Because 1. the
>> > number of people using Guix is not so high (yet!), so 2. I am almost
>> > sure we can name the people using "guix environment" in scripts ;-).
>>
>> I’m not so sure. Guix is already used in scientific workflows, and there
>> is existing third-party documentation about using `guix environment`.
>
> Please point me where.
> It will save me time instead of reinventing the wheel.
It was mentioned on this list.
Toggle quote (9 lines)
>> And can you name the people using `guix environment` by searching
>> backwards in their bash history?
>
> So what would break?
> Your workflow: spending 5 minutes to read the warning message and then pressing:
> C-a GUIX_ENVIRONMENT_DEPRACATED=1 guix environment <your-complicated-invokation>
>
> (unfair and bitter; sorry!)
I’m sorry that this makes you bitter. This is not my intention.
I’ll answer without bitterness: The original environment does not spawn
instantly. It takes many minutes until it is ready. If I then have to go
back, find the warning (it’s likely that I’d miss it, because these are
things that work, and suddenly they break, which I’m likely to only
figure out when the followup steps don’t work) and run it again, that
often means that I’m out of time to do what I actually wanted to do.
Despite that: Yes, this is a viable way. It is one of the less painful
ones. Maybe avoid calling it "DEPRECATED" and instead give it a more
descriptive name that does not imply that it will go away.
Mercurial uses HGPLAIN=1 to say "I want the version which will never
change established API". Best practice is to always use that in scripts
— and that is a stable best practice. But this is also slow to receive
new features.
If the old way to use guix environment is intended to actually be legacy
only, then it could be a way forward to also provide
GUIX_ENVIRONMENT_STABLE=1 which gives an API that is guaranteed to never
change the meaning of options again *after the change that’s been
started to brew in 2017*.
That would be a purely append-only API then, and while it would break
once, it would prevent such changes for the future.
For PR it might be possible to state that with this change, guix
environment as a tool reaches version 0.99 (to be updated to 1.0 after
sufficient testing).
Toggle quote (11 lines)
>> > And 3. the time to figure out what changed is really low -- especially
>> > with warnings and hints -- and "guix environment foo -- make" would
>> > return an error because of dependencies missing.
>>
>> It took me days to figure out the exact guix environment invocation that
>> allows me to build the tools for a paper I’m still working on. If that
>> breaks, that causes massive anxiety, because I then don’t know whether
>> I’ll find the time to fix it before I run into deadlines.
>
> Do you mean add GUIX_ENVIRONMENT_DEPRECATED=1 at the top of your script?
Yes, at every script. And remember to add it to every command I still
have in history.
Toggle quote (21 lines)
>> > Other said, I do not see myself use-cases where the scripts using
>> > "guix environment" need to be robust for time-travelling -- the same
>> > script used with current, past and future Guix versions -- because as
>> > it was said elsewhere: "environment" can be seen like "temporary
>> > profile". And temporary means... well temporary. ;-)
>>
>> The same script must always work with future versions. Otherwise the
>> software is volatile.
>
> Here is the real argument.
>
> It is a point of view. I would like to ear the one of others.
> If I understand well, Konrad agrees with you.
>
> I am fine with: the same script must always work with future versions.
>
> It is a strong statement and if the Guix project agrees then it must
> be documented. For example in this section [1].
>
> What do you think?
Only if this is actually the stance of the whole Guix project.
Currently this is the argument given by one person in an email
discussion. I think that it is a strong and important argument
(otherwise I would not have made it), but I’ve been wrong before.
Maybe the change to Guix environment now is for the best of the project.
I cannot actually see so clearly into the future that I could say
whether the churn due to the breaking change or the annoyance due to
suboptimal default behavior will be worse.
Toggle quote (10 lines)
>
>
>> You don’t need to be able to go back in time, but the path forward must
>> be without breakage.
>
> Talking about Reproducible Science, going back in time is the core
> issue. If one is able to go back in time and to run again the (almost)
> exact same version, then the future is not the issue.
The future is an issue, because you often have to use up-to-date
libraries. Just imagine using a rust-tool but being stuck in a 12 months
old environment that you cannot update without breakage.
Toggle quote (6 lines)
> Correct me if I misunderstand your point.
> Today, I write a script using X tools at time T. In the future, I want
> to re-run this script so all the X tools must have a path forward
> without any breakage. It is your point, right? But this never happens,
> there is always a breakage somewhere; and generally for good reasons.
No, and that’s the point. That’s also the point of the article: There
are tools which almost never break. And there are tools that almost
always break.
If you use a tool out of the latter group, you’re in for a world of
pain. It’s why it took years and years for somewhat stable git-wrappers
to appear: The early wrappers that made git easier to use always broke
when git changed operation. Guix environment might actually help you
delay the update until you have time to deal with the breakage.
Toggle quote (5 lines)
> Instead in this future, if I am able to restore the exact same X tools
> as they were at time T, my script still works.
>
> Well, this is another story.
This helps surviving volatility in other tools, but only if tool for
doing so isn’t volatile itself.
Toggle quote (8 lines)
>> > Last, "volatile" vs "stable" is mitigated by "The future of 'guix
>> > environment'" [1] which really predates the 1.0. ;-)
>>
>> Yepp, but we’re after 1.0 now. This might have been a blocker for 1.0,
>> but it wasn’t.
>
> So if the version bump, it is not an issue then, isn't it?
It would still be an issue, but see the part about seeing into the
future above :-)
Toggle quote (10 lines)
>> >> Also: Software developers should avoid traumatic changes
>> >> https://drewdevault.com/2019/11/26/Avoid-traumatic-changes.html
>> >
>> > "Traumatic changes"? Maybe a bit extreme for the change we are talking about...
>>
>> I don’t think so. There’s the strong version where it’s obvious: It
>> leads people to leave a project instantly.
>
> Yes, me!
Have a look at your reaction here. This is just the kind of reaction
people feel when something into which they invested time suddenly stops
working as expected.
Toggle quote (6 lines)
>> There’s the weaker version which is less obvious: That’s where people
>> who invested efford to follow best practices suddenly find their project
>> to be written in legacy style, because the best practices changed.
>
> Best practise depends on a lot of parameters. I did not know it was frozen.
If you manage to freeze the best practices without blocking ways into
the future, then you found part of the holy grail of software
development: You managed to find one fragment that’s so good that it
never needs to change again and everything new you do fits to it.
Typically reality isn’t quite as beautiful and change can break your
model. They say about Lisp that it’s a snowball: You can keep adding
stuff to it and it always stays a snowball. That’s close to this beauty.
But Lisp is also full of car/cdr-namings and legacy you cannot shed,
even though you might want to.
You cannot reach-and-keep perfection in a changing world, you can only
try to limit the pain for users and stay close to something which feels
right.
Volatile projects do not work to limit the pain.
Stale projects do not try to stay close to ways that feel right in a
changing reality.
A good project needs to get as close as possible to a consensus (I’m not
saying compromise here, because that’s not what I mean — the goal is
something which unites both) between not being volatile and not becoming
stale.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
