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: Wed, 1 Jan 2020 20:23:05 +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> <87tv5h7t0j.fsf@gnu.org> <87eewlo6yp.fsf@elephly.net> <87tv5gxt7x.fsf@gnu.org> <877e2cnwgs.fsf@elephly.net> 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]:43982) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1imjb9-0001Ne-44 for bug-guix@gnu.org; Wed, 01 Jan 2020 14:24:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1imjb7-0000eu-Vl for bug-guix@gnu.org; Wed, 01 Jan 2020 14:24:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:59850) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1imjb7-0000em-SL for bug-guix@gnu.org; Wed, 01 Jan 2020 14:24:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1imjb7-0006sl-Os for bug-guix@gnu.org; Wed, 01 Jan 2020 14:24:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <877e2cnwgs.fsf@elephly.net> 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: Ricardo Wurmus Cc: GNU Guix maintainers , 38529@debbugs.gnu.org Hi, Happy New Year! (if you are using a gregorian calendar based on the January 1srt reform) On Tue, 31 Dec 2019 at 20:09, Ricardo Wurmus wrote: > =E2=80=9Cprofile=E2=80=9D is a tempting choice, but it=E2=80=99s treacher= ous because we might be > blinded by the glow of the implementation of environments as volatile > profiles. On the other hand: if we could also move some of the features > of the =E2=80=9Cpackage=E2=80=9D sub-command under =E2=80=9Cprofile=E2=80= =9D (e.g. those that relate to > the management of, well, profiles), that could be a winning move. If the new "guix profile" does more or less the same thing than the current "guix environment", then I find the word "profile" confusing because the concept of "profile" is not exactly the same elsewhere. However, if the current CLI is changed is a bit, for example splitting the current "guix package", then why not. I mean, let consider the new command 'profile' with subcommands: - guix profile new - guix profile list etc. i.e., managing the profiles as it has been recently described (sorry too lazy to correctly refer where, but e.g., this thread [1]). *and* with the subcommand 'create' or 'temporary' or , i.e., "guix profile create" doing more or less what the current "guix environment" is doing. Wouaouw! It is far far away from the initial idea behind this thread. :-) [1] https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00565.html All the best, simon