From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism Date: Mon, 30 Dec 2019 13:03:19 +0100 Message-ID: References: <87eexeu8mo.fsf@ambrevar.xyz> <87k16vdise.fsf@gnu.org> <87zhfp2w11.fsf@web.de> <871rt03shq.fsf@web.de> <87zhfn3hgj.fsf@web.de> <87tv5upttv.fsf@elephly.net> <87o8w1mxjt.fsf@gnu.org> <87blrqp2pp.fsf@euandre.org> <878smu85kw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:41534) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iltmG-0006pX-Rs for bug-guix@gnu.org; Mon, 30 Dec 2019 07:04:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iltmE-0006zL-LX for bug-guix@gnu.org; Mon, 30 Dec 2019 07:04:04 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:54577) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iltmE-0006zE-Id for bug-guix@gnu.org; Mon, 30 Dec 2019 07:04:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iltmE-0002Oc-DE for bug-guix@gnu.org; Mon, 30 Dec 2019 07:04:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <878smu85kw.fsf@gnu.org> 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: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: EuAndreh , GNU Guix maintainers , 38529@debbugs.gnu.org Hi Ludo, On Mon, 30 Dec 2019 at 11:35, Ludovic Court=C3=A8s wrote: > > Wouldn't having a new name for the new behaviour avoid breakage in this > > situation? > > Yes, that=E2=80=99s correct (that=E2=80=99s also one of the suggestions K= onrad made). Is this statement acted? Is it the consensus by all the maintainers? And I am not clear about what will happens for "guix environment"? Deprecate for sure. But after X time: removed or frozen? Removing the command "guix environment" is against the backward compatibility argument because all the current documentation/scripts using it will not work anymore. Other said, if the documentation/scripts cannot be updated as it was said -- in favor for strong backward compatibility -- then the user will be surprised that what worked does not anymore because the command does not exist anymore. Therefore, if Guix goes the backward compatibility route, then the "guix environment" should be frozen until the version 2.0 and so only removed when the 2.0 will be released. Or I misunderstand the arguments in favor of the backward compatibility. As Arne described the process (bottom of [1]), "guix environment" will become a kind-of alias of "guix shell/". Right? > We could take that route. What would we call it, though? I don=E2=80=99= t like > =E2=80=9Cguix shell=E2=80=9D because it doesn=E2=80=99t quite reflect wha= t the command is > about. No good idea, though. Argh! Naming is hard. Something that reflects what the command is about: "guix environment"? (joke!! ;-)) Why do you say that "guix shell" does not reflect what the command is about= ? Because the command spawns a new shell with options (expanding it, isolating it, etc.) Well, because we do not seem having good idea for a new name, maybe if we argument why we collectively find that name or this name is bad or good, one of us will find the good name. Currently, "guix shell" seems the better option. All the best, simon