From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Hinsen Subject: Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism Date: Tue, 17 Dec 2019 07:49:21 +0100 Message-ID: References: <87eexeu8mo.fsf@ambrevar.xyz> <87k16vdise.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:54890) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ih6fe-00051M-Eb for guix-devel@gnu.org; Tue, 17 Dec 2019 01:49:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ih6fd-00083U-EG for guix-devel@gnu.org; Tue, 17 Dec 2019 01:49:26 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:34539) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ih6fd-000814-0N for guix-devel@gnu.org; Tue, 17 Dec 2019 01:49:25 -0500 In-Reply-To: <87k16vdise.fsf@gnu.org> Content-Language: en-US List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org, 38529@debbugs.gnu.org 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.