bug#38529: Deprecating ‘guix environment’?

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

Hi Konrad,


On Fri, 20 Dec 2019 at 12:18, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:

> My point of view (long form:
> https://hal.archives-ouvertes.fr/hal-02117588)
> is that software projects should adopt a backwards compatibility policy
> early on, state it clearly in their documentation, and stick to it. That
> prevents misunderstandings, bad surprises, and heated debates.

Thank you for the pointer. I have not read yet.
I agree with the compatibility policy and this argument has been
raises in the "heated" debate with Arne. :-)


> As for what that policy should be for Guix, that's a more difficult
> story. For projects with versioned releases, I like the principles

The first idea which comes in mind is to introduce a pledge. Maybe in
the introduction.

"The Guix project pledges to keep backward compatibility... blabla".

However, the real question is at which level.
At the CLI level? At the exported scheme functions? All modules or
specific ones?


> of semantic versioning, but Guix is more of a rolling-release
> project. (Test question: does anyone know what the current Guix version
> number is? Does anyone care?) I am not aware of any good precedents
> in terms of policy for such projects.

I agree.

I proposed [1] to add "tags" in the meaning of "git tag". Initially,
to ease the navigation through the history when searching for
packages.
Re-hashing this "guix tag" or "guix pull --tag" proposal, one idea
could be to introduce tags, say v1.1, v1.2, v1.3 etc bumping the
version every X months, or after each core-update merge, or after
<you-name-it>, then by default "guix pull" would update to the tags.
This adds "stability" because we could tag commits that we know are
stable (no "guix pull" break, etc.)

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


> > The hard question then becomes: what do we call it?  I vote against
> > abbreviations.  :-)
> >
> > Also, what other goals would we set for that command?  How would we
> > frame it in the set of commands?
>
> I vote for discussing the second point before the first one. Names
> should reflect the functionality behind them.

The starting point seems:
 - https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00300.html
 - what do you feel missing about "guix environment"?

Considering my use-case, I am mostly aligned with "The future of 'guix
environment'".



All the best,
simon