Hi zimoun, zimoun <zimon.touto...@gmail.com> 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=", "guix <command> --manifest=", "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’m 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’m still working on. If that breaks, that causes massive anxiety, because I then don’t know whether I’ll 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’t 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’s 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’re after 1.0 now. This might have been a blocker for 1.0, but it wasn’t. >> 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’t think so. There’s the strong version where it’s obvious: It leads people to leave a project instantly. There’s the weaker version which is less obvious: That’s where 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 > <you-name-it>"? I would opt for b. And then for changing guix to give the most common commands when called without argument (as `guix`) — 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/… 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 -- Unpolitisch sein heißt politisch sein ohne es zu merken
signature.asc
Description: PGP signature
