From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 19 17:40:52 2019 Received: (at submit) by debbugs.gnu.org; 19 Dec 2019 22:40:52 +0000 Received: from localhost ([127.0.0.1]:45691 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ii4TU-0006Ga-9U for submit@debbugs.gnu.org; Thu, 19 Dec 2019 17:40:52 -0500 Received: from lists.gnu.org ([209.51.188.17]:52501) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ii4TR-0006GJ-8J for submit@debbugs.gnu.org; Thu, 19 Dec 2019 17:40:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38188) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ii4TP-0006Pm-DQ for bug-guix@gnu.org; Thu, 19 Dec 2019 17:40:49 -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 1ii4TN-0007FK-5E for bug-guix@gnu.org; Thu, 19 Dec 2019 17:40:47 -0500 Received: from mail-qt1-x835.google.com ([2607:f8b0:4864:20::835]:39275) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ii4TM-0007CO-3Y; Thu, 19 Dec 2019 17:40:44 -0500 Received: by mail-qt1-x835.google.com with SMTP id e5so6480098qtm.6; Thu, 19 Dec 2019 14:40:43 -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=+ehepk2484gFuhzNPQYQvKZFfi9+Nk8MzaWVxGLs3mI=; b=k2yRArazh9zTP34D+ikw5FFLkT+/1n+qBUrjqSEFmTN2lO7htoEVfJUws80q0prkVp JYRuIU7rOk30BB+rFrcDOpNBvn5wG0Pf2BS3EU5Yid4gG07KRR1kTI79lYI6K66yeW/e l1Y/ZohwCSbYRA0ID0jb1I1G8yr4Oi2LCA+KcYePeXQzmdxLo/fPqmnwttFmBCVNTHWP B9t76P4YLNiThi4BtQScJFZ49j316Gv58h2GSs3Qi/aqZVljRY4t9TGQyu0fD40dSdef 44nwjBj57xFZpzpOEoKBl67O7qEALt408Ur/4n5ogna5SFV6aswLgOn6ywFzkAlFBVQ+ heCQ== 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=+ehepk2484gFuhzNPQYQvKZFfi9+Nk8MzaWVxGLs3mI=; b=jdGFCW/1EgucNNpIrX0sRfTg0HsPyDvZ1dxKPUY/SzaRsDlPCw1a4xaWBNlE/8KPWK 0LGtGiMkCZgV3/5hwuDfrHH6TwILock4nZjL0O1cowPNBR4dx59wgooP+id69QUE+qD3 X9bCNa6TrYqrEDIq258/MelKN4VQ1RxfT3aV6X88d1+rj4J/TwIQgLOn1et4ug/nCiwf 2Hw/PZbsyJGO9nn+AnQf/BQDZStu/RjqypFG90brEp2oKZ4jBFANYZPKztPmfByktctd oUEqwT3tg9prtqoRKbUjWtL2Nx0oov7aOXh5Eo5W/YK0PuPTMjoBX8FgF0mPbqHsm4HG nkAg== X-Gm-Message-State: APjAAAWb1msLEuQdlaJ2iZGfiZ1FgbjLWopZ4IfUfigy6qjnsdxpk3iU zQYbtjBEo4y7JqwhLKjtNb/W9sWbPrMpBYO/jRE= X-Google-Smtp-Source: APXvYqzqXdH4uVcPuDJ1vPxOYVJ1xhxJhxeF2KhqfrgwSWxM/te3yWjDeKldhV4SRwFB2bu4gQ4Km4TRytxy12cTJFA= X-Received: by 2002:ac8:1016:: with SMTP id z22mr9279864qti.217.1576795243078; Thu, 19 Dec 2019 14:40:43 -0800 (PST) MIME-Version: 1.0 References: <87eexeu8mo.fsf@ambrevar.xyz> <87k16vdise.fsf@gnu.org> <87zhfp2w11.fsf@web.de> <871rt03shq.fsf@web.de> In-Reply-To: <871rt03shq.fsf@web.de> From: zimoun Date: Thu, 19 Dec 2019 23:40:31 +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::835 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, First, have you read the proposal? Or are you (maybe a bit) "overreacting" about the backward compatibility? On Thu, 19 Dec 2019 at 22:39, Arne Babenhauserheide wrote= : > zimoun writes: > > 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", "gui= x > > 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. So you expect that we would push a patch changing "guix environment" and in the same time break "guix pull, isn't it? Otherwise I do not see your argument. > > 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=E2=80=99m not so sure. Guix is already used in scientific workflows, an= d there > is existing third-party documentation about using `guix environment`. Please point me where. It will save me time instead of reinventing the wheel. > And can you name the people using `guix environment` by searching > backwards in their bash history? So what would break? Your workflow: spending 5 minutes to read the warning message and then pres= sing: C-a GUIX_ENVIRONMENT_DEPRACATED=3D1 guix environment (unfair and bitter; sorry!) > > 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=E2=80=99m still working on. If= that > breaks, that causes massive anxiety, because I then don=E2=80=99t know wh= ether > I=E2=80=99ll find the time to fix it before I run into deadlines. Do you mean add GUIX_ENVIRONMENT_DEPRECATED=3D1 at the top of your script? > > 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. Here is the real argument. It is a point of view. I would like to ear the one of others. If I understand well, Konrad agrees with you. I am fine with: the same script must always work with future versions. It is a strong statement and if the Guix project agrees then it must be documented. For example in this section [1]. What do you think? [1] http://guix.gnu.org/manual/devel/en/html_node/Managing-Software-the-Gui= x-Way.html#Managing-Software-the-Guix-Way > You don=E2=80=99t need to be able to go back in time, but the path forwar= d must > be without breakage. Talking about Reproducible Science, going back in time is the core issue. If one is able to go back in time and to run again the (almost) exact same version, then the future is not the issue. Correct me if I misunderstand your point. Today, I write a script using X tools at time T. In the future, I want to re-run this script so all the X tools must have a path forward without any breakage. It is your point, right? But this never happens, there is always a breakage somewhere; and generally for good reasons. Instead in this future, if I am able to restore the exact same X tools as they were at time T, my script still works. Well, this is another story. > > Last, "volatile" vs "stable" is mitigated by "The future of 'guix > > environment'" [1] which really predates the 1.0. ;-) > > Yepp, but we=E2=80=99re after 1.0 now. This might have been a blocker for= 1.0, > but it wasn=E2=80=99t. So if the version bump, it is not an issue then, isn't it? > >> 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=E2=80=99t think so. There=E2=80=99s the strong version where it=E2= =80=99s obvious: It > leads people to leave a project instantly. Yes, me! > There=E2=80=99s the weaker version which is less obvious: That=E2=80=99s = where people > who invested efford to follow best practices suddenly find their project > to be written in legacy style, because the best practices changed. Best practise depends on a lot of parameters. I did not know it was frozen. Well, I withdraw my investment. I am not interested anymore to not tell that I am traumatized. Regards, simon