all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Arne Babenhauserheide <arne_bab@web.de>
To: zimoun <zimon.toutoune@gmail.com>
Cc: guix-devel@gnu.org, 38529@debbugs.gnu.org
Subject: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Date: Thu, 19 Dec 2019 22:39:13 +0100	[thread overview]
Message-ID: <871rt03shq.fsf@web.de> (raw)
In-Reply-To: <CAJ3okZ3bHnOzOk2Cdtvh_NZbYGDfA+zzxrAsJk+7=gRYHaL7jw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4202 bytes --]

Hi zimoun,

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

>>      Should Guix be volatile software?
>>      http://stevelosh.com/blog/2012/04/volatile-software/
>
> 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.

> Number of people         Time it takes each person
> using that part of   X   to figure out what changed
> the program              and how to fix it
>
> 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`.

And can you name the people using `guix environment` by searching
backwards in their bash history?

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

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

You don’t need to be able to go back in time, but the path forward must
be without breakage.

> Then, the section "The Tradeoff" advices "from newmodule import
> new_foo as foo" and IMO it is what the plan proposes with the variable
> GUIX_ENVIRONMENT_DEPRECATED (tricky point #4).

No, that’s the opposite: from newmodule import new_foo as foo means,
that you allow users to define an environment variable called
`GUIX_ENVIRONMENT_MODERN`.

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

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

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.

> Well, at the end, what is explicitly your personal opinion?
>  a. Change the behaviour of "guix environment" using the proposed plan?
> or
>  b. Add a new command? Which one? "guix shell", "guix env" or "guix
> <you-name-it>"?

I would opt for b. And then for changing guix to give the most common
commands when called without argument (as `guix`) — excluding
guix environment.

That would not avoid the slow version of traumatic changes, but if
guix environment would keep working and both guix env/guix shell/… and
guix environment used the same backend (just with different options),
then they would be minimized, because guix environment would not become
a second-class citizen.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]

  reply	other threads:[~2019-12-19 21:40 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-08 15:42 bug#38529: Make --pure the default for `guix environment'? Pierre Neidhardt
2019-12-08 21:03 ` zimoun
2019-12-09 18:46   ` Thompson, David
2019-12-09 20:17     ` Brett Gilio
2019-12-10 17:16     ` Ludovic Courtès
2019-12-30 17:27       ` raingloom
2020-11-03 17:38       ` Christopher Lemmer Webber
2020-11-03 18:35         ` zimoun
2020-11-06  9:03         ` Ludovic Courtès
2020-11-04  9:43       ` Taylan Kammer
2020-11-04 16:05         ` Christopher Lemmer Webber
2019-12-12 11:23   ` Make --ad-hoc the default for guix environment proposed deprecation mechanism Gábor Boskovits
2019-12-12 16:47     ` bug#38529: " zimoun
2019-12-12 16:47     ` zimoun
2019-12-12 20:54       ` Gábor Boskovits
2019-12-12 20:54       ` Gábor Boskovits
2019-12-13 12:02         ` zimoun
2019-12-13 16:27           ` Gábor Boskovits
2019-12-13 16:32             ` zimoun
2019-12-13 16:41               ` Gábor Boskovits
2019-12-14 18:11               ` Hartmut Goebel
2019-12-16 22:09             ` Ludovic Courtès
2019-12-17  6:49               ` Konrad Hinsen
2019-12-17  9:14                 ` Gábor Boskovits
2019-12-17  9:14                 ` Gábor Boskovits
2019-12-17 13:33                   ` Kyle Meyer
2019-12-17 14:22                     ` Brett Gilio
2019-12-17 14:22                     ` Brett Gilio
2019-12-17 13:33                   ` Kyle Meyer
2019-12-17 22:30                   ` Bengt Richter
2019-12-17 22:30                   ` Bengt Richter
2019-12-17 23:21                     ` Bengt Richter
2019-12-17 23:21                     ` Bengt Richter
2019-12-17 17:07                 ` zimoun
2019-12-18  9:43                   ` Konrad Hinsen
2019-12-18  9:43                   ` Konrad Hinsen
2019-12-18 13:09                     ` zimoun
2019-12-20 11:24                       ` Konrad Hinsen
2019-12-20 12:03                         ` zimoun
2019-12-20 21:08                           ` Ricardo Wurmus
2019-12-23  9:28                             ` Danny Milosavljevic
2019-12-23  9:28                             ` Danny Milosavljevic
2020-01-02  9:49                             ` Andy Wingo
2019-12-20 11:24                       ` Konrad Hinsen
2019-12-18 13:09                     ` zimoun
2019-12-18 20:55                     ` Arne Babenhauserheide
2019-12-19 11:30                       ` zimoun
2019-12-19 21:39                         ` Arne Babenhauserheide [this message]
2019-12-19 22:40                           ` zimoun
2019-12-20  1:37                             ` Arne Babenhauserheide
2019-12-20 11:40                               ` zimoun
2019-12-20 21:31                                 ` Ricardo Wurmus
2019-12-21  8:40                                   ` Gábor Boskovits
2019-12-21 16:51                                   ` Ludovic Courtès
2019-12-30  9:44                                     ` EuAndreh via Bug reports for GNU Guix
2019-12-30 10:34                                       ` Ludovic Courtès
2019-12-30 12:03                                         ` zimoun
2019-12-30 15:06                                           ` Ludovic Courtès
2019-12-30 17:55                                             ` zimoun
2019-12-30 21:10                                               ` Ricardo Wurmus
2019-12-30 21:32                                                 ` zimoun
2019-12-31 18:09                                                 ` Ludovic Courtès
2019-12-31 19:09                                                   ` Ricardo Wurmus
2020-01-01 19:23                                                     ` zimoun
2019-12-20 23:02                                 ` Arne Babenhauserheide
2019-12-21  0:04                                   ` zimoun
2019-12-20 21:12                     ` Ricardo Wurmus
2019-12-20 21:12                     ` Ricardo Wurmus
2019-12-21 15:18                       ` Konrad Hinsen
2019-12-21 15:18                       ` Konrad Hinsen
2019-12-17 17:07                 ` zimoun
2019-12-19 16:31                 ` Deprecating ‘guix environment’? Ludovic Courtès
2019-12-19 22:48                   ` zimoun
2019-12-19 22:48                   ` bug#38529: " zimoun
2019-12-20 11:17                   ` Konrad Hinsen
2019-12-20 13:21                     ` bug#38529: " zimoun
2019-12-20 13:21                     ` zimoun
2019-12-20 11:17                   ` bug#38529: " Konrad Hinsen
2019-12-19 16:31                 ` Ludovic Courtès
2019-12-17  6:49               ` bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism Konrad Hinsen
2019-12-16 22:09             ` Ludovic Courtès
2019-12-12 11:23   ` Gábor Boskovits
2019-12-08 22:43 ` bug#38529: Make --pure the default for `guix environment'? Leo Famulari
2019-12-09  5:23 ` Maxim Cournoyer
2022-08-19 14:28   ` Maxim Cournoyer
2019-12-09 17:37 ` Jesse Gibbons
2019-12-12 19:33   ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871rt03shq.fsf@web.de \
    --to=arne_bab@web.de \
    --cc=38529@debbugs.gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.