From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Hinsen Subject: bug#38529: Deprecating =?UTF-8?Q?=E2=80=98guix_?= =?UTF-8?Q?environment=E2=80=99=3F?= Date: Fri, 20 Dec 2019 12:17:37 +0100 Message-ID: References: <87eexeu8mo.fsf@ambrevar.xyz> <87k16vdise.fsf@gnu.org> <87k16snuoz.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]:48515) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iiGIG-000368-Cb for bug-guix@gnu.org; Fri, 20 Dec 2019 06:18:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iiGIE-00028G-UY for bug-guix@gnu.org; Fri, 20 Dec 2019 06:18:04 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:39976) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iiGIE-000271-MQ for bug-guix@gnu.org; Fri, 20 Dec 2019 06:18:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iiGIE-00085W-F8 for bug-guix@gnu.org; Fri, 20 Dec 2019 06:18:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87k16snuoz.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: guix-devel@gnu.org, 38529@debbugs.gnu.org Hi Ludo, > Clearly there=E2=80=99s a tension between that and keeping Guix open to c= hanges. That's indeed the main problem and here as elsewhere, it is often a topic of heated arguments. My point of view (long form: https://hal.archives-ouvertes.fr/hal-02117588) is that software projects should adopt a backwards compatibility policy early on, state it clearly in their documentation, and stick to it. That prevents misunderstandings, bad surprises, and heated debates. As for what that policy should be for Guix, that's a more difficult story. For projects with versioned releases, I like the principles of semantic versioning, but Guix is more of a rolling-release project. (Test question: does anyone know what the current Guix version number is? Does anyone care?) I am not aware of any good precedents in terms of policy for such projects. > The hard question then becomes: what do we call it? I vote against > abbreviations. :-) > > Also, what other goals would we set for that command? How would we > frame it in the set of commands? I vote for discussing the second point before the first one. Names should reflect the functionality behind them. How about a unified command for constructing environments and profiles declaratively? In other words, combine "guix environment" and the declarative parts of "guix package". We could probably get rid of the somewhat obscure "guix environment -r" in the process. Cheers, Konrad.