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

[zimoun]

Hi Arne,


On Fri, 20 Dec 2019 at 02:37, Arne Babenhauserheide <address@hidden> wrote:

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


I am fine. :-)
Life is about managing disagreements.
And I am probably a typical grouchy French. ;-)

Well, if we go back in time, the story is:
 - the original author of "guix environment" is not happy with the
current behaviour and proposes a change (see "The future of 'guix
environment'").
 - life happens (v1.0) but not this change.
 - I am not happy with the current behaviour and other on IRC neither.
 - a plan to change is opened for discussions.

The first concern by Ludo is about the compatibility.
Then Konrad raises concrete examples.

At this point, my personal opinion is: the cost is low so the change can happen.
However, I agree with the "backward compatibility" issue and even I
propose a name for this "new" command: "guix shell".

Then you ask one question: "Should Guix be volatile software?" with
the subtitle "Software developers should avoid traumatic changes".
Nothing more.
Well, I answer you by trying to fill the gap. Note that "volatile
software" is the same argument than the Ludo's concern and the
Konrad's example. So, nothing new on the table; except you are
starting to throw "feelings" with the "traumatic change" words.

Then, your following answer is more about your feelings than concrete
examples. It is hard to know in advance how many scripts or use-cases
would be broken -- i.e., estimate the cost -- and a way is to probe;
say: "it will break X of my scripts" or "in my institute, X people use
"guix environment blabla" daily, so it is not an option", etc.
Otherwise, it is unproductive.

Well, instead of arguing about feelings because it is going nowhere or
at better a flame war about "backward compatibility", I prefer going
to spend my time elsewhere (still about Guix :-)).
I mean, I proposed, I said my opinion and I called to collect more
opinions. I feel I did my best on this front and other fronts deserve
proposals and fixes.


Kind regards,
simon

ps:
Note that I did a proposal which could be a path to reduce the burden
of "guix pull" breakage: adding tags. Feel free to comment.

https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00513.html