Hi Arne, Thank you for the pointers.
On Wed, 18 Dec 2019 at 21:55, Arne Babenhauserheide <arne_...@web.de> wrote: > Konrad Hinsen <konrad.hin...@fastmail.net> writes: > >> Maybe I miss a point. It is not: "watch out, this will do something > >> else in the future" but "watch out, this was doing something else in > >> the past and the change happened the <date> in <commit>". > > > > Concrete example: I am writing a tutorial about using Guix for > > reproducible research. It shows several uses of "guix environment", some > > of them without '–add-hoc' or '–inputs-of'. I know my examples will > > cease to work in a few months. What am I supposed to do about this? > > This is the point where we need to ask ourselves: > > 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. Well, the section "The situation" just cannot(*) happen with Guix. That's why Guix is awesome! ;-) (*) well if one correctly uses Guix which is another story ;-) and it is not perfect yet... see all the discussion about manifest. :-) Now, let recall the formula (already discussed in this thread :-)) 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 ;-). 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. 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. ;-) 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). Last, "volatile" vs "stable" is mitigated by "The future of 'guix environment'" [1] which really predates the 1.0. ;-) [1] https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00300.html As I said, I am not convinced by the argument: everything would be broken, too much time to fix the break, etc. and this proposal would lead to disaster for the end-user. But it is my opinion based on my restricted personal experience. > 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... 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>"? All the best, simon
