From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 19 06:30:33 2019 Received: (at submit) by debbugs.gnu.org; 19 Dec 2019 11:30:33 +0000 Received: from localhost ([127.0.0.1]:44323 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ihu0m-0002Qv-Oh for submit@debbugs.gnu.org; Thu, 19 Dec 2019 06:30:33 -0500 Received: from lists.gnu.org ([209.51.188.17]:56194) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ihu0k-0002Qh-4E for submit@debbugs.gnu.org; Thu, 19 Dec 2019 06:30:31 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39733) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ihu0i-0007P2-L5 for bug-guix@gnu.org; Thu, 19 Dec 2019 06:30:29 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ihu0h-0002au-3T for bug-guix@gnu.org; Thu, 19 Dec 2019 06:30:28 -0500 Received: from mail-qv1-xf35.google.com ([2607:f8b0:4864:20::f35]:39261) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ihu0g-0002W0-RM; Thu, 19 Dec 2019 06:30:26 -0500 Received: by mail-qv1-xf35.google.com with SMTP id y8so2076477qvk.6; Thu, 19 Dec 2019 03:30:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sBxHxU3hrgyhV7XSTBtBf2RDjbLtRVFIElMqxwkOG1A=; b=MbVuaJtEVYJDhZY904Bf6EN5KTUqbRKlc7PUZey/Q9cCWsX0KXdnqLPQCH6zzxEqRd hpuA4vknGHw+lIi5JjgLDouBRCoIovHLlaS149/PZ27Kh8tp47rKmf0YKgCPhGKTAudL JjNofbgDii6EWq6MIjEKBeuRZEcE5GT4wRh9hxK2/ooP7G1+YxyBkIE+Y3SdzY8TS8eS 0BCEGb/breFwWCFndqok2jXEuaXfg7jMCUZwCw17O/BWq884PJ6UKc+enNdyDA2dwHhX 1GvwdreVkXaLeHTLU8uzfAqXlPC1/OYKC2T4DIHXXLUY0DqjTcj9bENq1lD1fepVt/wu kA3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sBxHxU3hrgyhV7XSTBtBf2RDjbLtRVFIElMqxwkOG1A=; b=YGtSzyTNuIutJiH8X5gOCUDOkBnZ+u/QhunekXxoQRBwvf5KTbd4TdIVPYuyQ9YbcC UXr2ksEU1ObmjXVyjm0nxZlghu88DpwvXjUKVZBWSYJlZnJcSA6gZPuZq5zthx8fSxsI dRTj/tXIajiniTKJFbGCnx6hzpShsVA64NHQJzPtMrk3AXbf0zTU5kg0/AwDjCEwbgXn AGqjVxuaRwsQ9jTJkVmWqgnEFbcaIM6bAlYSZabhNwXcvgvy4EZVptDjOpjJal11tESg /us43yOffBsI4jsUbE57HHNtBBoWDQMyVD0+MC2t1BD/5uNivTwiWdoYmwiwcPYAjig8 nEsA== X-Gm-Message-State: APjAAAVka0C9Ledtrur6xL6fl/TKBIsFybqaU7mrxCDk4v0bhXRqMCA4 VSvYHRHSbWAYUQuVGGqAlXi04lN5ageKgMTcU1E= X-Google-Smtp-Source: APXvYqwF9jHV+vrPjXo7cDy9BY+3bab9G7jpTf1wnPXB0skk1pX9u7pUQKSY+DXf91iI/K7qi1cGpI5FCidV6vPh4SY= X-Received: by 2002:a05:6214:3a1:: with SMTP id m1mr6790436qvy.77.1576755025485; Thu, 19 Dec 2019 03:30:25 -0800 (PST) MIME-Version: 1.0 References: <87eexeu8mo.fsf@ambrevar.xyz> <87k16vdise.fsf@gnu.org> <87zhfp2w11.fsf@web.de> In-Reply-To: <87zhfp2w11.fsf@web.de> From: zimoun Date: Thu, 19 Dec 2019 12:30:14 +0100 Message-ID: Subject: Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism To: Arne Babenhauserheide Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::f35 X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: Guix Devel , bug-guix@gnu.org, 38529@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) 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