[bug#50960] [PATCH 00/10] Add 'guix shell' to subsume 'guix environment'

[zimoun]

Hi,

On Mon, 04 Oct 2021 at 10:39, Ludovic Courtès <ludo@gnu.org> wrote:

> It should be clear from the code that I generally prefer explicit over
> implicit :-), but I think Dave has a point when talking about
> conventions for this kind of developer tool.

Well, if you speak about this thread [1], the point is others are doing
so and it is an usability improvement. :-)

I am fine since somehow it is already the case with ’make’ or all the
config files or many of us seem to simplify their workflow using direnv
or etc.  so yes it is probably handy to have conventions and automatic
load by default. :-)

1: <https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00300.html>


>>> As for deprecation, I think there’s no rush.  I imagine there could be
>>> several phases, like: initially we only mention deprecation in the manual,
>>> later on ‘guix environment’ starts emitting a warning, and later (I guess
>>> at least two years later, probably more) we ask ourselves whether to
>>> remove ‘guix environment’.  At this point keeping it doesn’t cost us much.
>>
>> Concretely, I propose this plan:
>>
>>  - v1.4: mention deprecation in the manual and remove from “guix help”
>>  - v1.5: emit a warning
>>  - v1.6: remove the command
>
> Could be like this.  I guess we could also slow down the plan if we
> observe that ‘guix environment’ sticks around longer than we thought.

Bah, let reconsider this when preparing v1.6. ;-)  At the current
release rate, probably 2024. :-)

>From my point of view, we should clearly document at v1.4 that this
command will be removed soon or later.


>> Well, I do not see why the removal should be an issue, because there is
>> “guix time-machine”.  To me, the real issue is to let people knowing
>> such change.
>
> As discussed in <https://issues.guix.gnu.org/38529#17>, removal is an
> issue because of existing scripts but also because of learning material
> around: MOOCs, articles, tutorials, etc.  These won’t be updated
> overnight, and we owe our users stability.

For sure, I agree «we owe our users stability».  That’s I translate into
«the real issue is to let people knowing such change». :-)

As I am trying to explain, this scenario,

  guix environment <options> <packages>
  … wait several months or years …
  guix pull
  guix environment <options> <packages>

will break because <packages>.  Therefore, one will have to fix these
very same scripts.  Even us, we are not able to maintain working scripts
for different points in time.  The example using “guix environment” is
broken for the manual released at v1.3, as pointed here [2].

However, “guix environment” will still work using “guix time-machine”.
Nothing is really broken, IMHO.

About learning materials, we could remove the command “guix environment”
but keep a section in the manual explaining how to switch to the new
“guix shell”.

Well, let discuss all that when preparing v1.5 or v1.6.  Something as
one or two years from now. ;-)  Which i

2: <http://issues.guix.gnu.org/47097>


Cheers,
simon