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: Thu, 19 Dec 2019 22:39:13 +0100 Message-ID: <871rt03shq.fsf@web.de> References: <87eexeu8mo.fsf@ambrevar.xyz> <87k16vdise.fsf@gnu.org> <87zhfp2w11.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]:42275) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ii3We-0000Xy-1I for bug-guix@gnu.org; Thu, 19 Dec 2019 16:40:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ii3Wc-0001cl-Bb for bug-guix@gnu.org; Thu, 19 Dec 2019 16:40:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:39645) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ii3Wc-0001bX-65 for bug-guix@gnu.org; Thu, 19 Dec 2019 16:40:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ii3Wc-0004kY-33 for bug-guix@gnu.org; Thu, 19 Dec 2019 16:40: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 Hi zimoun, zimoun writes: >> 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. 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. > 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 ;-). I=E2=80=99m not so sure. Guix is already used in scientific workflows, and = there is existing third-party documentation about using `guix environment`. And can you name the people using `guix environment` by searching backwards in their bash history? > 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 t= hat breaks, that causes massive anxiety, because I then don=E2=80=99t know whet= her I=E2=80=99ll find the time to fix it before I run into deadlines. > 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. You don=E2=80=99t need to be able to go back in time, but the path forward = must be without breakage. > 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). No, that=E2=80=99s the opposite: from newmodule import new_foo as foo means, that you allow users to define an environment variable called `GUIX_ENVIRONMENT_MODERN`. > 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. >> 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 ab= out... 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. There=E2=80=99s the weaker version which is less obvious: That=E2=80=99s wh= ere people who invested efford to follow best practices suddenly find their project to be written in legacy style, because the best practices changed. > 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 > "? I would opt for b. And then for changing guix to give the most common commands when called without argument (as `guix`) =E2=80=94 excluding guix environment. That would not avoid the slow version of traumatic changes, but if guix environment would keep working and both guix env/guix shell/=E2=80=A6 = and guix environment used the same backend (just with different options), then they would be minimized, because guix environment would not become a second-class citizen. 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+sFAl377gMACgkQE++NRSQD w+tujBAAxS1DE0VL+KlggoUcM1PXzAVqmznzZOn3/M24/n2tCWCiK7QfXBOCK3dt QXSYpoozIV2ZHdjc8UpM6Y+xwr+WnJrQsvQAIKOwDT7Dzxa4RHsNV9PmFHOxyJFM as7t4XxYfXJrp48n6baF/xywvrMcWe0L2F8x1e2PF0SXrHKMwb+cg+k0pE0H+02z 5n1fd4O6VetyPa3U0XQGcmMqqxDaPY7kfXCA+daqry4/T/F6xli0T9NOBK1C/a4I IQP+YenYlyzKKXTCiZ+0mm6/vx+hGQzvkmGPDYsFsUTvz10dGLEBDoZOTHECcWVN guYEHNDpItMrt/JueN4x7MXwV6eclviaIo8rHMIg1UO4F81KjRwN2Ejr4T46+utX 6uvE0k5QPH6Ol01sHDBvfNvC/XztGgN0BJtmsMn5CtbhQx1BWHbNrNVbJIY4Fzev 5fBwB7psKG4yDpb58xtgs84PbN5gAK3jW31brOGrTprYpPoQQxxIluXd02vk7j6T /qNroGg3H3W1Q4hHEPCBdtJVAF2lAylCDraPo9eU4j/+odrQDMqB2ISfGbO69xQe LVMvM0UaGVuf4LJfk0rED4eppm9sib0KjgE5Fdy3W9ur/hS94WIBO6XqC6w/35UG WP9wMGDZGWY+donOfO3JZWSmzbjncsUhHJ32bXm6FlN/MWvkM8eIswQBAQgAHRYh BN0ovebZh1yrzkqLHdzPDbMLwQVIBQJd++4DAAoJENzPDbMLwQVIPHAD/0ozQwSH Xe6qMlZHPs8FDOqXxcX+3onf+Kir9UVQuxUl+jnJTh5FL9vlWvdRb5yk7vKXnY7D 2eZ5x68w3Y4sdl9hma+CiFit+M4H5vKQhOGpNTgKHllnVGJ5DFM96V8b4TZR9J3r vr49IjXgbsWP6X+KCE2rULP+YjjzmiCcJIk7 =pDkB -----END PGP SIGNATURE----- --=-=-=--