From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism Date: Thu, 19 Dec 2019 12:30:14 +0100 Message-ID: References: <87eexeu8mo.fsf@ambrevar.xyz> <87k16vdise.fsf@gnu.org> <87zhfp2w11.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <87zhfp2w11.fsf@web.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Arne Babenhauserheide Cc: Guix Devel , bug-guix@gnu.org, 38529@debbugs.gnu.org List-Id: bug-guix.gnu.org Hi Arne, Thank you for the pointers. On Wed, 18 Dec 2019 at 21:55, Arne Babenhauserheide wrote= : > Konrad Hinsen 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 in ". > > > > Concrete example: I am writing a tutorial about using Guix for > > reproducible research. It shows several uses of "guix environment", som= e > > of them without '=E2=80=93add-hoc' or '=E2=80=93inputs-of'. I know my e= xamples 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=3D", "guix --manifest=3D", "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 abou= t... 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 "? All the best, simon