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

[Ludovic Courtès]

Hi!

Ricardo Wurmus <address@hidden> skribis:

> I’m just chiming in here to say that feelings of frustration are very
> valid reasons to make or object to a change.  Guix is or can be a very
> important piece of software — if it remains reliable in the toolbox of
> those using it.
>
> It is difficult striking the right balance between exciting new features
> that make things possible that were previously unattainable and
> dependability through stable interfaces.
>
> The Guix command line is by far the most commonly used interface.  We
> can’t just claim that the Scheme API is stable (which it actually isn’t)
> and change the user-facing CLI as we please.

Agreed.

> Personally, I think that it is fine to introduce breaking changes, but
> that for changes that are likely to have a high potential for annoyance
> and frustration there ought to be a documented way to work around them.
> Breaking changes must be communicated through version number bumps and
> accompanying announcements.

Yes, I think it is clear that we’d have to do this using all the tools
at our disposal, including time.

Konrad’s objection remains though: existing documents (papers, blog
posts, MOOCs, etc.) that mention ‘guix environment’ would all of a
sudden become wrong if we were to change the defaults of ‘guix
environment’.  Even if we introduce a variable to restore the old
behavior.

Perhaps that’s unavoidable in the long run, but perhaps this is not the
right time for this.

> While I don’t see how we can make it happen, I do find the idea of a
> stable API whose version can be selected with an environment variable
> intriguing and worth thinking about.  If our Scheme API is as flexible
> as we claim it shouldn’t be too hard to interpose a configuration layer
> between the core facilities and the “porcelain”.

You mean a stable Scheme API, or a stable CLI?

To me, a stable CLI is definitely the goal.  As for the Scheme API, I
would distinguish core APIs, peripheral APIs (e.g., the importers), (gnu
system …) APIs, and packages.  I’d aim for high stability for core APIs,
be laxer for peripheral APIs, even laxer for the remaining.

I’m not sure what you mean about adding a configuration layer between
the core facilities (the core Scheme APIs?) and the porcelain?

Thanks,
Ludo’.