Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
On Fri 20 Dec 2019 22:08, Ricardo Wurmus writes: > zimoun writes: > >> - I propose the name "guix shell" > > This is not a bad idea, especially considering that “guix environment” > was meant to get shebang support, so that you could use it as the > interpreter in a script that handles the environment configuration. > > It is also shorter. I like this idea. It would also allow us to deprecate "guix environment" over a period of a year or so, and we can probably show an equivalent "guix shell" invocation in the deprecation message. Andy
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Ricardo, On Fri, 20 Dec 2019 22:08:48 +0100 Ricardo Wurmus wrote: > zimoun writes: > > > - I propose the name "guix shell" > > This is not a bad idea, especially considering that “guix environment” > was meant to get shebang support, so that you could use it as the > interpreter in a script that handles the environment configuration. Note that the Linux kernel shebang interpreter only supports ONE argument. The good news is that whatever number of arguments you pass, it will all be subsumed into the first argument. #!foo bar baz foo gets: $1="bar baz", $#=2 pgpQ8n2VWdlCk.pgp Description: OpenPGP digital signature
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Ricardo, > I wonder if we should simply bump the version number to indicate that > this is a breaking change? That's a possibility, but who ever looks at Guix version numbers? > Another more difficult option would be to do what responsible API > developers on the web do: to version their API and to make the API > version selectable. I don’t know *how* to do this elegantly, and That's an interesting idea which would also take care of similar situations in the future. One way to implement this is to have executables "guix1", "guix2" etc. Most users would then define an alias "guix" for interactive use, but hopefully script authors would use the versioned executables. Cheers, Konrad.
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Arne, First, do not take me wrong, I am not "fighting" or not going to an "heated debate". I am fine and I hope you are also fine. As I said my opinion in other emails, I am not repeating here. Well, I am not convinced it is the good one, but as I trust collective power, I am sure Guix will find the best consensus. I am even calling since the very beginning of this discussion to collect opinions from the other fellow hackers. Expressing the feelings is better than bitterness. Therefore I express mines. :-) I could send that privately because I am not sure it deserves to be public. But let wash the laundry in family (translation from French expression ;-)) On Sat, 21 Dec 2019 at 00:02, Arne Babenhauserheide wrote: > > Konrad's example. So, nothing new on the table; except you are > > starting to throw "feelings" with the "traumatic change" words. > > I do not see this as feelings, but as strategy. That’s what the article > is about: Many small breakages add up, and repeated changes to > best-practices also add up. Just to be on the same wavelength, traumatic means in the Collins Dictionnary: "A 'traumatic' experience is very shocking and upsetting, and may cause psychological damage." https://www.collinsdictionary.com/dictionary/english/traumatic Well, to me it could make sense in the context of the mentioned blog. Even if I feel this very opinionated. Not to say it could hurt me; bah I am a big boy, that's ok. Again, to be on the same wavelength, the blog says: "The result has been hugely divisive and intimately familiar to anyone who works with Python, creating massive rifts in the community and wasting millions of hours of engineer time addressing. This kind of “strong” trauma is fairly easy to spot in advance." Well, I understand when speaking about Python. Are we comparing the number of Guix users with the number of Python users? Are we comparing the number of changes between Python 2 and 3 with the change of the default "guix environment foo"? And not all the "guix environment" behaviour, only a specific case. Ok, maybe we are talking about the other trauma. The blog explains: "Since nothing has actually broken with this change, the effects are more subtle than with strong traumatic changes." and then "The opportunity to solve this problem by rewriting with asyncio in mind, however, also presents me a chance to rewrite in anything else, and reevaluate my choice of Python for the project entirely." I am sorry, I do not understand. I am probably too dumb. On one hand, the issue of "guix environment" is the very backward compatibility so are we really talking about this second "trauma"? On the other hand, because "guix environment" will be better and users probably need to rethink how they use Guix, then they will fully drop Guix. Maybe "feelings" (quoting, in citation quoted too) is not the right word. My point is all is vague. Example: I have the feeling that my students(*) do not like Scheme; do I need to switch next year to another language? Then do I make my decision based on my feelings? based on the feelings of the students who are retaking the year (could be shocked)? Me, I will make my decision based on: how many students failed? what do they understand? what could be better for all the students? what could be a better language? what is the ratio between the new student vs the retaking ones? how many length the Scheme textbook is? etc. Well, analogy is just analogy. Well, that's it. I expressed what it appears to me a trail going nowhere. Let move forward and put energy in "backward compatibility" discussion: does Guix want? what does it imply? which level? etc. for example, your interesting input "GUIX_ENVIRONMENT_STABLE=1". All the best, simon (*) hypothetical, I do not have real students, even if I teach a bit. And we use Python as introduction to implemented algorithms after 1 year fighting to switch from C. Whatever! :-)
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi zimoun, zimoun writes: > Konrad's example. So, nothing new on the table; except you are > starting to throw "feelings" with the "traumatic change" words. I do not see this as feelings, but as strategy. That’s what the article is about: Many small breakages add up, and repeated changes to best-practices also add up. The volatile software article describes that software differs in how much work it is to keep using it. The traumatic change article discusses one aspect why people stop using projects. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
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", some > of them without '–add-hoc' or '–inputs-of'. I know my examples will > cease to work in a few months. What am I supposed to do about this? I wonder if we should simply bump the version number to indicate that this is a breaking change? Another more difficult option would be to do what responsible API developers on the web do: to version their API and to make the API version selectable. I don’t know *how* to do this elegantly, and there’s a real maintenance cost (it seems small in this case), but configuration files can be used for changing new defaults. -- Ricardo
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
zimoun writes: > - I propose the name "guix shell" This is not a bad idea, especially considering that “guix environment” was meant to get shebang support, so that you could use it as the interpreter in a script that handles the environment configuration. It is also shorter. -- Ricardo
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Konrad, On Fri, 20 Dec 2019 at 12:24, Konrad Hinsen wrote: > The problem is scripts circulating in public repositories, tutorials, > etc. New users will find them and use them for inspiration. It's very > discouraging to see examples from tutorials fail or do something weird. As I said, I am not convinced because it lacks concrete examples. Personally, I do not know Guix ressource outside the Guix ecosystem. > The main precedent is the Python 2->3 transition. There are tons of > GitHub repositories with Python code but no indication if it's 2, 3, or > both. I even had to use one that executed with either 2 or 3, but gave > different results. It takes a lot of motivation to persist. Except that "guix environment" will raise warnings. Whatever. > For guix, there's the additional issue that we use the reproducibility > of builds as an argument. Non-reproducible examples are then a bit of a > credibility problem. I agree. I do not want to fight about "backward compatibility". As I said, talking about "guix environment", my opinion is that the cost of the change is low. However, we cannot know this cost, only probe and estimate: using my probings, I estimate the cost is low. IMHO, in this case, there is 2 ways to make a decision: - more probings to estimate more precisely; or - say: "no backward compatibility breakage" I am fine with both. :-) - I report my use-case: no cost at all - I propose the name "guix shell" However, I feel I have spent enough time and energy on this topic and I feel a blocking situation so I will move forward to another topic. :-) All the best, simon
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Arne, On Fri, 20 Dec 2019 at 02:37, Arne Babenhauserheide wrote: > > Or are you (maybe a bit) "overreacting" about the backward compatibility? > > I don’t think so. I am definitely reacting strongly, but that’s because > breakages in Guix have already cost me the evenings of several weeks > this year. > > But before I write anything more, I’d like to ask you to take a step > back to breathe. > > We’re discussing a change in software. We disagree on the way forward, > but I’m 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 — because that actually helps. > It’s what I try to do when discussions get vexing. > > I am grateful that you’re taking up improvements in Guix, and there are > situations where viewpoints are different. That is OK. I am fine. :-) Life is about managing disagreements. And I am probably a typical grouchy French. ;-) Well, if we go back in time, the story is: - the original author of "guix environment" is not happy with the current behaviour and proposes a change (see "The future of 'guix environment'"). - life happens (v1.0) but not this change. - I am not happy with the current behaviour and other on IRC neither. - a plan to change is opened for discussions. The first concern by Ludo is about the compatibility. Then Konrad raises concrete examples. At this point, my personal opinion is: the cost is low so the change can happen. However, I agree with the "backward compatibility" issue and even I propose a name for this "new" command: "guix shell". Then you ask one question: "Should Guix be volatile software?" with the subtitle "Software developers should avoid traumatic changes". Nothing more. Well, I answer you by trying to fill the gap. Note that "volatile software" is the same argument than the Ludo's concern and the Konrad's example. So, nothing new on the table; except you are starting to throw "feelings" with the "traumatic change" words. Then, your following answer is more about your feelings than concrete examples. It is hard to know in advance how many scripts or use-cases would be broken -- i.e., estimate the cost -- and a way is to probe; say: "it will break X of my scripts" or "in my institute, X people use "guix environment blabla" daily, so it is not an option", etc. Otherwise, it is unproductive. Well, instead of arguing about feelings because it is going nowhere or at better a flame war about "backward compatibility", I prefer going to spend my time elsewhere (still about Guix :-)). I mean, I proposed, I said my opinion and I called to collect more opinions. I feel I did my best on this front and other fronts deserve proposals and fixes. Kind regards, simon ps: Note that I did a proposal which could be a path to reduce the burden of "guix pull" breakage: adding tags. Feel free to comment. https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00513.html
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Simon, > Assuming "guix environment" would stay and following the proposed > plan, you would need to add GUIX_ENVIRONMENT_DEPRECATED=1 on the top > of your script. In this would not be a problem for travelling back in > time. The problem is not how I update my scripts - I can manage that, no matter what it takes. The problem is scripts circulating in public repositories, tutorials, etc. New users will find them and use them for inspiration. It's very discouraging to see examples from tutorials fail or do something weird. The main precedent is the Python 2->3 transition. There are tons of GitHub repositories with Python code but no indication if it's 2, 3, or both. I even had to use one that executed with either 2 or 3, but gave different results. It takes a lot of motivation to persist. For guix, there's the additional issue that we use the reproducibility of builds as an argument. Non-reproducible examples are then a bit of a credibility problem. Cheers, Konrad.
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
zimoun writes: > First, have you read the proposal? Yes. > Or are you (maybe a bit) "overreacting" about the backward compatibility? I don’t think so. I am definitely reacting strongly, but that’s because breakages in Guix have already cost me the evenings of several weeks this year. But before I write anything more, I’d like to ask you to take a step back to breathe. We’re discussing a change in software. We disagree on the way forward, but I’m 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 — because that actually helps. It’s what I try to do when discussions get vexing. I am grateful that you’re 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’m not so sure. Guix is already used in scientific workflows, and 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 > pressing: > C-a GUIX_ENVIRONMENT_DEPRACATED=1 guix environment > > > (unfair and bitter; sorry!) I’m sorry that this makes you bitter. This is not my intention. I’ll answer without bitterness: The original environment does not spawn instantly. It takes many minutes until it is ready. If I then have to go back, find the warning (it’s likely that I’d miss it, because these are things that work, and suddenly they break, which I’m likely to only figure out when the followup steps don’t work) and run it again, that often means that I’m 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=1 to say "I want the version which will never change established API". Best practice is to always use that in scripts — and that is a stable best practice. But this is also slow to receive 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=1 which gives an API that is guaranteed to never change the meaning of options again *after the change that’s 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’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. > > Do you mean add GUIX_ENVIRONMENT_DEPRECATED=1 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
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
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=", "guix --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. 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’m not so sure. Guix is already used in scientific workflows, and 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 pressing: C-a GUIX_ENVIRONMENT_DEPRACATED=1 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’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. Do you mean add GUIX_ENVIRONMENT_DEPRECATED=1 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-Guix-Way.html#Managing-Software-the-Guix-Way > You don’t need to be able to go back in time, but the path forward 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’re after 1.0 now. This might have been a blocker for 1.0, > but it wasn’t. 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’t think so. There’s the strong version where it’s obvious: It > leads people to leave a project instantly. Yes, me! > 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. 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
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
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=", "guix --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 > "? 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
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
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", some > > of them without '–add-hoc' or '–inputs-of'. I know my examples 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=", "guix --manifest=", "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 about... 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
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Konrad Hinsen writes: > Hi Simon, > >> 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", some > of them without '–add-hoc' or '–inputs-of'. I know my examples 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/ Also: Software developers should avoid traumatic changes https://drewdevault.com/2019/11/26/Avoid-traumatic-changes.html Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Konrad, On Wed, 18 Dec 2019 at 10:43, Konrad Hinsen wrote: > > Hi Simon, > > > 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", some > of them without '–add-hoc' or '–inputs-of'. I know my examples will > cease to work in a few months. What am I supposed to do about this? Assuming "guix environment" would stay and following the proposed plan, you would need to add GUIX_ENVIRONMENT_DEPRECATED=1 on the top of your script. In this would not be a problem for travelling back in time. > > First, I am not convinced that there is not so much scripts that will > > be broken. And second, I am not convinced neither that these very > > scripts need time-traveling. > > Perhaps it's just me, but I use "guix environment" quite a lot in > scripts, in order to make them more reproducible. Here's a simple > example: > >#!/usr/bin/env bash >guix environment --container --ad-hoc gcc-toolchain./pi >EOF With the proposed plan, this would stay the same. Even, the --ad-hoc option could stay forever for backward compatibility. The only issue is for example: #!/usr/bin/env bash guix environment --container gmsh < > Yes, it is probably the most adequate to do. But it is sad to loose > > the good name "guix environment"... and we know that naming is hard. > > ;-) > > I definitely agree. As a lesson for the future, maybe we should use > not-so-nice names for new commands during a kind of beta-testing phase. What do you think about "guix shell" for the new "guix environment" behaviour? What the others think? New name (easier) vs transitional plan (trickier)? And new names proposal: - guix env - guix shell ? All the best, simon
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Simon, > 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", some of them without '–add-hoc' or '–inputs-of'. I know my examples will cease to work in a few months. What am I supposed to do about this? > First, I am not convinced that there is not so much scripts that will > be broken. And second, I am not convinced neither that these very > scripts need time-traveling. Perhaps it's just me, but I use "guix environment" quite a lot in scripts, in order to make them more reproducible. Here's a simple example: #!/usr/bin/env bash guix environment --container --ad-hoc gcc-toolchain <> The first rule of backwards-compatibility is: never change the meaning >> of an existing valid command/API. Add new valid syntax, deprecate old >> valid syntax, but don't change the meaning of something that was and >> will be valid. > > I agree on the rule. > But it is mitigated but the number of users and the popularity of the tool. > ;-) Indeed! > Yes, it is probably the most adequate to do. But it is sad to loose > the good name "guix environment"... and we know that naming is hard. > ;-) I definitely agree. As a lesson for the future, maybe we should use not-so-nice names for new commands during a kind of beta-testing phase. Cheers, Konrad
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Forgot to add: ┌──┐ │ guile -c '(use-modules (ice-9 session))(apropos "env") │ ├──┤ │ (guile): getenv # │ │ (guile): environ # │ │ (guile): setenv # │ │ (guile): interaction-environment # │ │ (guile): putenv # │ │ (guile): unsetenv # │ └──┘ BTW, it would be really handy to be able to type guile -apropos rest of line as regex for the effect of ,a rest of line as regex in the guile repl -- Regards, Bengt Richter
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Gábor, Konrad, et al On +2019-12-17 10:14:12 +0100, Gábor Boskovits wrote: > Hello Konrad, > > Konrad Hinsen ezt írta (időpont: 2019. dec. > 17., Ke 7:52): > > > On 16/12/2019 23:09, Ludovic Courtès wrote: > > > So in a more algorithmic manner: > > >> 1. if ad-hoc and inputs-of is present at the same invocation: fail > > >> hard. (With an error like incompatible options present) > > >> 2. if only ad-hoc is present, then print a deprecation warning (yes, > > >> we could make this suspendable with an environment variable, like you > > >> described) > > >> 3. if only inputs-of present, then do the new behaviour. > > >> 4. if neither ad-hoc nor inputs-of present then > > >>a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, > > >>b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the > > >> new behaviour. > > > That sounds like a good plan to me. > > > > > > #4 is the trickiest, and I think it’d be good to give users a bit of > > > time so they can start adjusting before deprecation is in effect. > > > > #4 is trickiest for another reason: there is no future-proof use of > > "guix environment" that works right now and will continue to work. Nor > > is there any way to see, when looking at a command line, whether it's > > old-style or new-style, if neither --ad-hoc nor --inputs-of are present. > > This means that all existing documentation (tutorials etc.) will become > > misleading in the future. Worse, even documentation written today, in > > full awareness of a coming change, can't do better than saying "watch > > out, this will do something else in the future". > > > > The first rule of backwards-compatibility is: never change the meaning > > of an existing valid command/API. Add new valid syntax, deprecate old > > valid syntax, but don't change the meaning of something that was and > > will be valid. > > I think it is important to consider context when talking about meaning. 1. the level and the interpreter of the command: The first level is usually the shell (typicallly bash) from logind, but there is systemd and/or shepherd before that, and there is bootloader and UEFI and before that also accepting and/or passing commands through to the kernel via the kernel command line (cf. cat /proc/cmdline ). The general pattern I mostly see for a given interpreter is verb -adverb* (-adjective-for: object-name)* sub-command? implicit-or-object-for-verb* Consider whether your new name reinforces a good convention or forks it. Consider whether proposed usage translates easily to a natural language explanation. Does guix have a cli design best practices doc, BTW? right now we are talking about the use case where verb=guix and subcommand=environment 2. project community conventions Specialized areas often have their own jargon and abbreviated refrences so an unfortunate choice of name can cause distracting disambiguation searches. Before settling on a new name xxx, even for a sub-command, I would say at least first do the following at the command line: which xxx xxx --version xxx --help info xxx man xxx apropos xxx #check for same prefix, case-insensitively, # e.g. env might be tempting, as seen in this thread :) --8<---cut here---start->8--- echo $PATH|tr : $'\n'|while read pdir;do (find "$pdir" -maxdepth 1 -iname "env*" 2>/dev/null);done --8<---cut here---end--->8--- # -name "*xxx*" may also be a good idea, but the prefix is most important # env* produces /usr/bin/env /usr/bin/envsubst guix search xxx guix package -A xxx wikipedia search on xxx, e.g. lynx -dump -force_html -nolist https://en.wikipedia.org/w/index.php?search=xxx |less You get the idea, I'm sure ;-) > > How about a more drastic measure: deprecate "guix environment" and > > introduce a new subcommand with the desired new behaviour? > > SGTM, with some caveats Good, since calling different things by the same name is always going to be problematic. Iffy, since calling the same thing by different names may reduce future naming options, and may muddy the peer-name namespace, so maybe consider using sub-commands or -adverb. > That is also the other option I was thinking about. Do you have any good > idea in mind as how to call it? Of course the classic guix environment2 > comes to my mind, but it does not look very appealing to me. > Me neither :) > > > > Cheers, > > > >Konrad. > > > Best regard, > g_bor > HTH in some way :) -- Regards, Bengt Richter
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Konrad, On Tue, 17 Dec 2019 at 07:52, Konrad Hinsen wrote: > > On 16/12/2019 23:09, Ludovic Courtès wrote: > > So in a more algorithmic manner: > >> 1. if ad-hoc and inputs-of is present at the same invocation: fail > >> hard. (With an error like incompatible options present) > >> 2. if only ad-hoc is present, then print a deprecation warning (yes, > >> we could make this suspendable with an environment variable, like you > >> described) > >> 3. if only inputs-of present, then do the new behaviour. > >> 4. if neither ad-hoc nor inputs-of present then > >>a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, > >>b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the > >> new behaviour. > > That sounds like a good plan to me. > > > > #4 is the trickiest, and I think it’d be good to give users a bit of > > time so they can start adjusting before deprecation is in effect. > > #4 is trickiest for another reason: there is no future-proof use of > "guix environment" that works right now and will continue to work. Nor > is there any way to see, when looking at a command line, whether it's > old-style or new-style, if neither --ad-hoc nor --inputs-of are present. > This means that all existing documentation (tutorials etc.) will become > misleading in the future. Worse, even documentation written today, in > full awareness of a coming change, can't do better than saying "watch > out, this will do something else in the future". I do not understand what is the issue for the time-traveling if it is documented. 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 ". First, I am not convinced that there is not so much scripts that will be broken. And second, I am not convinced neither that these very scripts need time-traveling. > The first rule of backwards-compatibility is: never change the meaning > of an existing valid command/API. Add new valid syntax, deprecate old > valid syntax, but don't change the meaning of something that was and > will be valid. I agree on the rule. But it is mitigated but the number of users and the popularity of the tool. ;-) > How about a more drastic measure: deprecate "guix environment" and > introduce a new subcommand with the desired new behaviour? Yes, it is probably the most adequate to do. But it is sad to loose the good name "guix environment"... and we know that naming is hard. ;-) What about "guix shell"? All the best, simon
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Dec 17, 2019 7:34:17 AM Kyle Meyer : > G�bor Boskovits writes: > > > > Konrad Hinsen ezt �rta (id?pont: 2019. dec. > > 17., Ke 7:52): > > > [...] > > > > > > How about a more drastic measure: deprecate "guix environment" and > > > introduce a new subcommand with the desired new behaviour? > > > > > > > > That is also the other option I was thinking about. Do you have any good > > idea in mind as how to call it? Of course the classic guix environment2 > > comes to my mind, but it does not look very appealing to me. > > > > Perhaps "guix env"? > +1 for guix env
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Gábor Boskovits writes: > Konrad Hinsen ezt írta (időpont: 2019. dec. > 17., Ke 7:52): [...] >> How about a more drastic measure: deprecate "guix environment" and >> introduce a new subcommand with the desired new behaviour? >> > That is also the other option I was thinking about. Do you have any good > idea in mind as how to call it? Of course the classic guix environment2 > comes to my mind, but it does not look very appealing to me. Perhaps "guix env"?
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hello Konrad, Konrad Hinsen ezt írta (időpont: 2019. dec. 17., Ke 7:52): > On 16/12/2019 23:09, Ludovic Courtès wrote: > > So in a more algorithmic manner: > >> 1. if ad-hoc and inputs-of is present at the same invocation: fail > >> hard. (With an error like incompatible options present) > >> 2. if only ad-hoc is present, then print a deprecation warning (yes, > >> we could make this suspendable with an environment variable, like you > >> described) > >> 3. if only inputs-of present, then do the new behaviour. > >> 4. if neither ad-hoc nor inputs-of present then > >>a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, > >>b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the > >> new behaviour. > > That sounds like a good plan to me. > > > > #4 is the trickiest, and I think it’d be good to give users a bit of > > time so they can start adjusting before deprecation is in effect. > > #4 is trickiest for another reason: there is no future-proof use of > "guix environment" that works right now and will continue to work. Nor > is there any way to see, when looking at a command line, whether it's > old-style or new-style, if neither --ad-hoc nor --inputs-of are present. > This means that all existing documentation (tutorials etc.) will become > misleading in the future. Worse, even documentation written today, in > full awareness of a coming change, can't do better than saying "watch > out, this will do something else in the future". > > The first rule of backwards-compatibility is: never change the meaning > of an existing valid command/API. Add new valid syntax, deprecate old > valid syntax, but don't change the meaning of something that was and > will be valid. > > How about a more drastic measure: deprecate "guix environment" and > introduce a new subcommand with the desired new behaviour? > That is also the other option I was thinking about. Do you have any good idea in mind as how to call it? Of course the classic guix environment2 comes to my mind, but it does not look very appealing to me. > > > Cheers, > >Konrad. > Best regard, g_bor > > > >
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
On 16/12/2019 23:09, Ludovic Courtès wrote: So in a more algorithmic manner: 1. if ad-hoc and inputs-of is present at the same invocation: fail hard. (With an error like incompatible options present) 2. if only ad-hoc is present, then print a deprecation warning (yes, we could make this suspendable with an environment variable, like you described) 3. if only inputs-of present, then do the new behaviour. 4. if neither ad-hoc nor inputs-of present then a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the new behaviour. That sounds like a good plan to me. #4 is the trickiest, and I think it’d be good to give users a bit of time so they can start adjusting before deprecation is in effect. #4 is trickiest for another reason: there is no future-proof use of "guix environment" that works right now and will continue to work. Nor is there any way to see, when looking at a command line, whether it's old-style or new-style, if neither --ad-hoc nor --inputs-of are present. This means that all existing documentation (tutorials etc.) will become misleading in the future. Worse, even documentation written today, in full awareness of a coming change, can't do better than saying "watch out, this will do something else in the future". The first rule of backwards-compatibility is: never change the meaning of an existing valid command/API. Add new valid syntax, deprecate old valid syntax, but don't change the meaning of something that was and will be valid. How about a more drastic measure: deprecate "guix environment" and introduce a new subcommand with the desired new behaviour? Cheers, Konrad.
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hello, Gábor Boskovits skribis: > So in a more algorithmic manner: > 1. if ad-hoc and inputs-of is present at the same invocation: fail > hard. (With an error like incompatible options present) > 2. if only ad-hoc is present, then print a deprecation warning (yes, > we could make this suspendable with an environment variable, like you > described) > 3. if only inputs-of present, then do the new behaviour. > 4. if neither ad-hoc nor inputs-of present then > a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, > b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the > new behaviour. That sounds like a good plan to me. #4 is the trickiest, and I think it’d be good to give users a bit of time so they can start adjusting before deprecation is in effect. Namely, we could start by introducing ‘--inputs-of’ and emitting a warning in case #4 to suggest the use of ‘--inputs-of’. Apart from the warning, case #4 would still behave the same as now. Three (?) months later, we implement what you describe above. Hopefully by that time many people got used to ‘--inputs-of’. Thoughts? Ludo’.
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi, > 4. if neither ad-hoc nor inputs-of present then > a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, > b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the > new behaviour. One remark: I suggest the test to be "set to a non-empty string" resp. "unset or empty". This is the way many programs to such checks. In shell this would be `[ -n "$VAR" ] ` and `[ -n "$VAR" ]`. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hello Zimoun, zimoun ezt írta (időpont: 2019. dec. 13., P, 17:32): > > Hi Gábor, > > Sorry to be slow. :-) I probably just did not express myself clearly enough. > > On Fri, 13 Dec 2019 at 17:28, Gábor Boskovits wrote: > > > > So in a more algorithmic manner: > > 1. if ad-hoc and inputs-of is present at the same invocation: fail > > hard. (With an error like incompatible options present) > > 2. if only ad-hoc is present, then print a deprecation warning (yes, > > we could make this suspendable with an environment variable, like you > > described) > > 3. if only inputs-of present, then do the new behaviour. > > 4. if neither ad-hoc nor inputs-of present then > > a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, > > b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the > > new behaviour. > > > > This would minimze friction, as there will be a few scripts falling under 4. > > This would also allow mirgating such scripts one by one. be defining > > GUIX_ENVIRONMENT_DEPRECATED to 1 in some startup file, and using > > GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... in scripts that are > > fixed to use the new syntax. > > > > > > What do you think? > > I am perfectly aligned! :-) Great! > It is exactly what I have tried to describe. > Sorry again for being slow. I am sorry for the confusion, my communication tends to slugghish, an I am also a bit bound to do some hand-waving :) I hope to improve on that > > Thank you. > Do you plan to implement it? Do I give a try? I would like to hear something from Ludo, as he was also a participant of the IRC discussion. After that I would not mind if you gave it a try, if you would like. Otherwise I will implement it. > > > All the best, > simon Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Gábor, Sorry to be slow. :-) On Fri, 13 Dec 2019 at 17:28, Gábor Boskovits wrote: > So in a more algorithmic manner: > 1. if ad-hoc and inputs-of is present at the same invocation: fail > hard. (With an error like incompatible options present) > 2. if only ad-hoc is present, then print a deprecation warning (yes, > we could make this suspendable with an environment variable, like you > described) > 3. if only inputs-of present, then do the new behaviour. > 4. if neither ad-hoc nor inputs-of present then > a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, > b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the > new behaviour. > > This would minimze friction, as there will be a few scripts falling under 4. > This would also allow mirgating such scripts one by one. be defining > GUIX_ENVIRONMENT_DEPRECATED to 1 in some startup file, and using > GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... in scripts that are > fixed to use the new syntax. > > > What do you think? I am perfectly aligned! :-) It is exactly what I have tried to describe. Sorry again for being slow. Thank you. Do you plan to implement it? Do I give a try? All the best, simon
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hello, Let me try again :) zimoun ezt írta (időpont: 2019. dec. 13., P, 13:02): > > Hi Gábor, > > > On Thu, 12 Dec 2019 at 21:54, Gábor Boskovits wrote: > > > zimoun ezt írta (időpont: 2019. dec. 12., Csü > > 17:47): > > >> Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option > >> with a different effect? Or why do we want to conserve this option > >> name? > >> It appears to me simpler to give another name, for example > >> "--inputs-of". And it is more meaningful. > > > > Sorry for the confusion. Ad-hoc should be retained with the same effect, so > > that we do not break existing scripts. > > Renamin the option would be ok. It even makes sense to me. > > What I propose is: > > - keep the option "--ad-hoc" with the current behavior; so same effect > - add a new option "--inputs-of" with the new behavior; name more meaningful > - and two env variables; to not break existing scripts > > > >> First, when "--ad-hoc" is used then it reports a warning: deprecated > >> option and falls in the current behavior. > >> When "--inputs-of" is used then it falls in the new behavior. > >> Therefore, no needs of the ugly "--ignore-deprecated-ad-hoc". > > > > That could be done. The problem is caused by uses of guix environment that > > does not use any of these options. Those mean different things after the > > change. > > The transition to such use-case was described below with the > introduction of 2 env variables. :-) > > > >> # Alice > >> $ guix environment foo --ad-hoc bar > >> Warning: deprecated... explanations... > >>instead use: > >> guix environment bar --inputs-of foo > >> > >> # Bob > >> $ guix environment bar --inputs-of foo > >> > >> > >> Second, the previous "guix environment foo" (dependencies of foo) is > >> inconsistent with the new "guix environment bar" (only the package > >> bar). Therefore, let introduce the GUIX_ENVIRONMENT_DEPRECATED > >> variable to distinguish both, as you said. > > > > Ok. > > It is the easy part. ;-) > > > Now the hard part: avoid to break existing scripts. > > >> # Alice > >> $ guix environment foo > >> Warning: previous behavior requires GUIX_ENVIRONMENT_DEPRECATED=1 > >>turn off the warning: GUIX_ENVIRONMENT_NOWARNING=1 > >> > >> And Alice has now a new shell with the package foo. If she wants the > >> dependencies, she has two options: > >> > >> $ GUIX_ENVIRONMENT=1 guix environment foo > >> or > >> $ guix environment --inputs-of foo > >> > >> > >> # Bob > >> $ guix environment bar > >> Warning: previous behavior requires GUIX_ENVIRONMENT > >> > >> And if Bob is annoyed by the warnings each time, he globally turns off > >> with the variable GUIX_ENVIRONMENT_NOWARNING=1. > >> > >> > >> Couple of months later -- after the period adoption -- we remove the > >> variables GUIX_ENVIRONMENT_NOWARNING and GUIX_ENVIRONMENT_DEPRECATED; > >> still keeping the warning with the "--ad-hoc" option. And then, after > >> we can remove the "--ad-hoc" option if required. > > > > We could recommend simply to use something like: > > GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... > > Instead in existing scripts that are fixed to use the new syntax. This > > indeed looks like a better solution, and it is less of a maintenance > > burden. Good idea. > > My point is: the new variable GUIX_ENVIRONMENT_DEPRECATED should only > be used by the scripts that call "guix environment pkg" without the > options "--ad-hoc" or "--inputs-of". And I think that it represents > really few scripts in real life. :-) > > > > Summarizing: > > Introduce the environment variable. > > For fixed scripts recommend unsetting the environment variable. > > I am not to get your plan. :-) > > > Cheers, > simon So in a more algorithmic manner: 1. if ad-hoc and inputs-of is present at the same invocation: fail hard. (With an error like incompatible options present) 2. if only ad-hoc is present, then print a deprecation warning (yes, we could make this suspendable with an environment variable, like you described) 3. if only inputs-of present, then do the new behaviour. 4. if neither ad-hoc nor inputs-of present then a. if GUIX_ENVIRONMENT_DEPRECATED is 1: do the current behaviour, b. if GUIX_ENVIRONMENT_DEPRECATED is undefined, or is not 1: do the new behaviour. This would minimze friction, as there will be a few scripts falling under 4. This would also allow mirgating such scripts one by one. be defining GUIX_ENVIRONMENT_DEPRECATED to 1 in some startup file, and using GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... in scripts that are fixed to use the new syntax. What do you think? Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Gábor, On Thu, 12 Dec 2019 at 21:54, Gábor Boskovits wrote: > zimoun ezt írta (időpont: 2019. dec. 12., Csü > 17:47): >> Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option >> with a different effect? Or why do we want to conserve this option >> name? >> It appears to me simpler to give another name, for example >> "--inputs-of". And it is more meaningful. > > Sorry for the confusion. Ad-hoc should be retained with the same effect, so > that we do not break existing scripts. > Renamin the option would be ok. It even makes sense to me. What I propose is: - keep the option "--ad-hoc" with the current behavior; so same effect - add a new option "--inputs-of" with the new behavior; name more meaningful - and two env variables; to not break existing scripts >> First, when "--ad-hoc" is used then it reports a warning: deprecated >> option and falls in the current behavior. >> When "--inputs-of" is used then it falls in the new behavior. >> Therefore, no needs of the ugly "--ignore-deprecated-ad-hoc". > > That could be done. The problem is caused by uses of guix environment that > does not use any of these options. Those mean different things after the > change. The transition to such use-case was described below with the introduction of 2 env variables. :-) >> # Alice >> $ guix environment foo --ad-hoc bar >> Warning: deprecated... explanations... >>instead use: >> guix environment bar --inputs-of foo >> >> # Bob >> $ guix environment bar --inputs-of foo >> >> >> Second, the previous "guix environment foo" (dependencies of foo) is >> inconsistent with the new "guix environment bar" (only the package >> bar). Therefore, let introduce the GUIX_ENVIRONMENT_DEPRECATED >> variable to distinguish both, as you said. > > Ok. It is the easy part. ;-) Now the hard part: avoid to break existing scripts. >> # Alice >> $ guix environment foo >> Warning: previous behavior requires GUIX_ENVIRONMENT_DEPRECATED=1 >>turn off the warning: GUIX_ENVIRONMENT_NOWARNING=1 >> >> And Alice has now a new shell with the package foo. If she wants the >> dependencies, she has two options: >> >> $ GUIX_ENVIRONMENT=1 guix environment foo >> or >> $ guix environment --inputs-of foo >> >> >> # Bob >> $ guix environment bar >> Warning: previous behavior requires GUIX_ENVIRONMENT >> >> And if Bob is annoyed by the warnings each time, he globally turns off >> with the variable GUIX_ENVIRONMENT_NOWARNING=1. >> >> >> Couple of months later -- after the period adoption -- we remove the >> variables GUIX_ENVIRONMENT_NOWARNING and GUIX_ENVIRONMENT_DEPRECATED; >> still keeping the warning with the "--ad-hoc" option. And then, after >> we can remove the "--ad-hoc" option if required. > We could recommend simply to use something like: > GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... > Instead in existing scripts that are fixed to use the new syntax. This indeed > looks like a better solution, and it is less of a maintenance burden. Good > idea. My point is: the new variable GUIX_ENVIRONMENT_DEPRECATED should only be used by the scripts that call "guix environment pkg" without the options "--ad-hoc" or "--inputs-of". And I think that it represents really few scripts in real life. :-) > Summarizing: > Introduce the environment variable. > For fixed scripts recommend unsetting the environment variable. I am not to get your plan. :-) Cheers, simon
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hello, zimoun ezt írta (időpont: 2019. dec. 12., Csü 17:47): > Hi Gábor, > > Thank you for summarizing the discussion on IRC that I missed. > > Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option > with a different effect? Or why do we want to conserve this option > name? > It appears to me simpler to give another name, for example > "--inputs-of". And it is more meaningful. > Sorry for the confusion. Ad-hoc should be retained with the same effect, so that we do not break existing scripts. Renamin the option would be ok. It even makes sense to me. > > > To be concrete, the different cases; (-) means current behavior and > (+) the new one: > > 1. > - guix environment foo > + guix environment --inputs-of foo > > 2. > - guix environment --ad-hoc bar > + guix environment bar > > > First, when "--ad-hoc" is used then it reports a warning: deprecated > option and falls in the current behavior. > When "--inputs-of" is used then it falls in the new behavior. > Therefore, no needs of the ugly "--ignore-deprecated-ad-hoc". > That could be done. The problem is caused by uses of guix environment that does not use any of these options. Those mean different things after the change. > > > In other words, with the same future guix version, > > # Alice > $ guix environment foo --ad-hoc bar > Warning: deprecated... explanations... >instead use: > guix environment bar --inputs-of foo > > # Bob > $ guix environment bar --inputs-of foo > > > Second, the previous "guix environment foo" (dependencies of foo) is > inconsistent with the new "guix environment bar" (only the package > bar). Therefore, let introduce the GUIX_ENVIRONMENT_DEPRECATED > variable to distinguish both, as you said. > Ok. > > # Alice > $ guix environment foo > Warning: previous behavior requires GUIX_ENVIRONMENT_DEPRECATED=1 >turn off the warning: GUIX_ENVIRONMENT_NOWARNING=1 > > And Alice has now a new shell with the package foo. If she wants the > dependencies, she has two options: > > $ GUIX_ENVIRONMENT=1 guix environment foo > or > $ guix environment --inputs-of foo > > > # Bob > $ guix environment bar > Warning: previous behavior requires GUIX_ENVIRONMENT > > And if Bob is annoyed by the warnings each time, he globally turns off > with the variable GUIX_ENVIRONMENT_NOWARNING=1. > > > Couple of months later -- after the period adoption -- we remove the > variables GUIX_ENVIRONMENT_NOWARNING and GUIX_ENVIRONMENT_DEPRECATED; > still keeping the warning with the "--ad-hoc" option. And then, after > we can remove the "--ad-hoc" option if required. > > > Maybe a miss a point. But the addition of the flag appears > "--too-long-to-type" to me ugly. > We could recommend simply to use something like: GUIX_ENVIRONMENT_DEPRECATED=0 guix environment ... Instead in existing scripts that are fixed to use the new syntax. This indeed looks like a better solution, and it is less of a maintenance burden. Good idea. > > > What do you think? > > All the best, > simon > Summarizing: Introduce the environment variable. For fixed scripts recommend unsetting the environment variable. That looks like a better plan. Thanks for your insights. Best regards, g_bor >
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Gábor, Thank you for summarizing the discussion on IRC that I missed. Maybe I miss a point. Is the aim to conserve the "--ad-hoc" option with a different effect? Or why do we want to conserve this option name? It appears to me simpler to give another name, for example "--inputs-of". And it is more meaningful. To be concrete, the different cases; (-) means current behavior and (+) the new one: 1. - guix environment foo + guix environment --inputs-of foo 2. - guix environment --ad-hoc bar + guix environment bar First, when "--ad-hoc" is used then it reports a warning: deprecated option and falls in the current behavior. When "--inputs-of" is used then it falls in the new behavior. Therefore, no needs of the ugly "--ignore-deprecated-ad-hoc". In other words, with the same future guix version, # Alice $ guix environment foo --ad-hoc bar Warning: deprecated... explanations... instead use: guix environment bar --inputs-of foo # Bob $ guix environment bar --inputs-of foo Second, the previous "guix environment foo" (dependencies of foo) is inconsistent with the new "guix environment bar" (only the package bar). Therefore, let introduce the GUIX_ENVIRONMENT_DEPRECATED variable to distinguish both, as you said. # Alice $ guix environment foo Warning: previous behavior requires GUIX_ENVIRONMENT_DEPRECATED=1 turn off the warning: GUIX_ENVIRONMENT_NOWARNING=1 And Alice has now a new shell with the package foo. If she wants the dependencies, she has two options: $ GUIX_ENVIRONMENT=1 guix environment foo or $ guix environment --inputs-of foo # Bob $ guix environment bar Warning: previous behavior requires GUIX_ENVIRONMENT And if Bob is annoyed by the warnings each time, he globally turns off with the variable GUIX_ENVIRONMENT_NOWARNING=1. Couple of months later -- after the period adoption -- we remove the variables GUIX_ENVIRONMENT_NOWARNING and GUIX_ENVIRONMENT_DEPRECATED; still keeping the warning with the "--ad-hoc" option. And then, after we can remove the "--ad-hoc" option if required. Maybe a miss a point. But the addition of the flag appears "--too-long-to-type" to me ugly. What do you think? All the best, simon
