bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism

[zimoun <zimon.toutoune@gmail.com>]

Hi Arne,

First, have you read the proposal?
Or are you (maybe a bit) "overreacting" about the backward compatibility?


On Thu, 19 Dec 2019 at 22:39, Arne Babenhauserheide <arne_bab@web.de> wrote:

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

> > Guix is not a volatile software and will never be. Because it is
> > rooted in time-travelling.
> > The tools "guix pull --commit=", "guix <command> --manifest=", "guix
> > time-machine" or the "--roll-back" avoid to break what is currently
> > working.
>
> 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?
Otherwise I do not see your argument.


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


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


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


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


[1] http://guix.gnu.org/manual/devel/en/html_node/Managing-Software-the-Guix-Way.html#Managing-Software-the-Guix-Way


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

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



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


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


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



Well, I withdraw my investment. I am not interested anymore to not
tell that I am traumatized.


Regards,
simon