From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arne Babenhauserheide Subject: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism Date: Fri, 20 Dec 2019 02:37:32 +0100 Message-ID: <87zhfn3hgj.fsf@web.de> References: <87eexeu8mo.fsf@ambrevar.xyz> <87k16vdise.fsf@gnu.org> <87zhfp2w11.fsf@web.de> <871rt03shq.fsf@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:55032) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ii7F1-0001iI-0X for bug-guix@gnu.org; Thu, 19 Dec 2019 20:38:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ii7Ex-00060I-GO for bug-guix@gnu.org; Thu, 19 Dec 2019 20:38:06 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:39778) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ii7Ew-0005tf-8B for bug-guix@gnu.org; Thu, 19 Dec 2019 20:38:03 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ii7Ew-00028M-43 for bug-guix@gnu.org; Thu, 19 Dec 2019 20:38:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: zimoun Cc: guix-devel@gnu.org, 38529@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable zimoun writes: > First, have you read the proposal? Yes. > Or are you (maybe a bit) "overreacting" about the backward compatibility? I don=E2=80=99t think so. I am definitely reacting strongly, but that=E2=80= =99s because breakages in Guix have already cost me the evenings of several weeks this year. But before I write anything more, I=E2=80=99d like to ask you to take a step back to breathe. We=E2=80=99re discussing a change in software. We disagree on the way forwa= rd, but I=E2=80=99m not attacking you as a person, and I hope it does not feel = that way to you. If it does: This is not my intention. Please take a moment to sigh deeply, shake your head, relax, and smile =E2=80=94 because that actually h= elps. It=E2=80=99s what I try to do when discussions get vexing. I am grateful that you=E2=80=99re taking up improvements in Guix, and there= are situations where viewpoints are different. That is OK. >> 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? No, this is an example which shows that being able to roll back does not mean that there is no problem with breaking the way forward. Using only old versions is often not an option. Just imagine running audio software from 5 years ago on a system that only provides pulseaudio (or whatever will come after it). Imagine using an old KDE DCOP-based automation workflow on a dbus-system. You need to update the libraries you use to get it working at all. >> > 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, a= nd there >> is existing third-party documentation about using `guix environment`. > > Please point me where. > It will save me time instead of reinventing the wheel. It was mentioned on this list. For the scientific workflows, see https://hpc.guix.info/ >> 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 pr= essing: > C-a GUIX_ENVIRONMENT_DEPRACATED=3D1 guix environment > > (unfair and bitter; sorry!) I=E2=80=99m sorry that this makes you bitter. This is not my intention. I=E2=80=99ll answer without bitterness: The original environment does not s= pawn instantly. It takes many minutes until it is ready. If I then have to go back, find the warning (it=E2=80=99s likely that I=E2=80=99d miss it, becau= se these are things that work, and suddenly they break, which I=E2=80=99m likely to only figure out when the followup steps don=E2=80=99t work) and run it again, th= at often means that I=E2=80=99m out of time to do what I actually wanted to do. Despite that: Yes, this is a viable way. It is one of the less painful ones. Maybe avoid calling it "DEPRECATED" and instead give it a more descriptive name that does not imply that it will go away. Mercurial uses HGPLAIN=3D1 to say "I want the version which will never change established API". Best practice is to always use that in scripts =E2=80=94 and that is a stable best practice. But this is also slow to rece= ive new features. If the old way to use guix environment is intended to actually be legacy only, then it could be a way forward to also provide GUIX_ENVIRONMENT_STABLE=3D1 which gives an API that is guaranteed to never change the meaning of options again *after the change that=E2=80=99s been started to brew in 2017*. That would be a purely append-only API then, and while it would break once, it would prevent such changes for the future. For PR it might be possible to state that with this change, guix environment as a tool reaches version 0.99 (to be updated to 1.0 after sufficient testing). >> > 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. I= f that >> breaks, that causes massive anxiety, because I then don=E2=80=99t know w= hether >> 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? Yes, at every script. And remember to add it to every command I still have in history. >> > 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? Only if this is actually the stance of the whole Guix project. Currently this is the argument given by one person in an email discussion. I think that it is a strong and important argument (otherwise I would not have made it), but I=E2=80=99ve been wrong before. Maybe the change to Guix environment now is for the best of the project. I cannot actually see so clearly into the future that I could say whether the churn due to the breaking change or the annoyance due to suboptimal default behavior will be worse. > [1] http://guix.gnu.org/manual/devel/en/html_node/Managing-Software-the-G= uix-Way.html#Managing-Software-the-Guix-Way > > >> You don=E2=80=99t need to be able to go back in time, but the path forwa= rd 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. The future is an issue, because you often have to use up-to-date libraries. Just imagine using a rust-tool but being stuck in a 12 months old environment that you cannot update without breakage. > 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. No, and that=E2=80=99s the point. That=E2=80=99s also the point of the arti= cle: There are tools which almost never break. And there are tools that almost always break. If you use a tool out of the latter group, you=E2=80=99re in for a world of pain. It=E2=80=99s why it took years and years for somewhat stable git-wrap= pers to appear: The early wrappers that made git easier to use always broke when git changed operation. Guix environment might actually help you delay the update until you have time to deal with the breakage. > 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. This helps surviving volatility in other tools, but only if tool for doing so isn=E2=80=99t volatile itself. >> > 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 fo= r 1.0, >> but it wasn=E2=80=99t. > > So if the version bump, it is not an issue then, isn't it? It would still be an issue, but see the part about seeing into the future above :-) >> >> 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! Have a look at your reaction here. This is just the kind of reaction people feel when something into which they invested time suddenly stops working as expected. >> 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 froze= n. If you manage to freeze the best practices without blocking ways into the future, then you found part of the holy grail of software development: You managed to find one fragment that=E2=80=99s so good that it never needs to change again and everything new you do fits to it. Typically reality isn=E2=80=99t quite as beautiful and change can break your model. They say about Lisp that it=E2=80=99s a snowball: You can keep adding stuff to it and it always stays a snowball. That=E2=80=99s close to this be= auty. But Lisp is also full of car/cdr-namings and legacy you cannot shed, even though you might want to. You cannot reach-and-keep perfection in a changing world, you can only try to limit the pain for users and stay close to something which feels right. Volatile projects do not work to limit the pain. Stale projects do not try to stay close to ways that feel right in a changing reality. A good project needs to get as close as possible to a consensus (I=E2=80=99= m not saying compromise here, because that=E2=80=99s not what I mean =E2=80=94 th= e goal is something which unites both) between not being volatile and not becoming stale. Best wishes, Arne =2D- Unpolitisch sein hei=C3=9Ft politisch sein ohne es zu merken --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl38Jd8ACgkQE++NRSQD w+vC8g/8CTt/lgrSap1zl00qvgCOBd3OIiabwzGWWP47FW/pQhQbhQ9Pq6+qs9Rv 2e5SOcPsA208rOz5acQrrEdzlj3XjM/1WFTmDtyu8mA7ROypQktV5Djy3oTGPPiN WEScyzIAOsLI07rhineOr950JXlStuS2aN6gBUshbGThPBG4Qz+zLgBZ6F3/QPEb 2XKFMkeGS2dDBmWk/F9u4/liC6WWP7RPl1jZLUC5pxVRZvqUNnjM2TXeBmlv3ItG LzQ5LriOUrZrUVE/xLE1NjjTbLlzzn3yL5yVh8NCt6KoAc9BkOg6yjk671YHaxj2 GHFTJHXWvY+sYGAp1+YIj6c1zYPfadMmbPx3SwftLcetv7zUxk4HPVZB9FwToLsk Gw8ow1M2n5XBurufkpa2UzJ7leJSP+PH++EU0u8+hbTbpKwTNtkrlPmdPdk17lWp uzumBs33Fzbzo7nBdkM7keTsqepNusq0KlLUmLQNJCYqYtELxsPSvYguFkr6XBzd mp95vYi37V0rWLsrUW6xx8wYTz9WAYUgki2DKvD5ZuTdSO9AHCup5zTjIDdE+KV+ mgfSuKegHLa3yTUE1Z/C25GFicSyHLIU9seYs6cac8Hvv9MziD00osd8meCU+w0Q fDV1xhQ9NRrkcKGtDTnAuosBkoA7EfMDRIbJ0245tGBUr3fVK82IswQBAQgAHRYh BN0ovebZh1yrzkqLHdzPDbMLwQVIBQJd/CXfAAoJENzPDbMLwQVIVb4D/3ZHXk97 aeV6d0bwuvAic/Rbjg08RAx2gP4IOopHI+/TWL0O7dCv1OW6jDAW5k36iAGaJhD0 6lIrUPH+LvCbpI2buacb1O0PO13BLUAVLkFoteLRMJiaiM8Juvoz/W87mNkDEsVB Ggtf5r3qKTGur+I8jnY5bavuGCEjTDKfk1Xh =VZF0 -----END PGP SIGNATURE----- --=-=-=--