[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#38529: Make --ad-hoc the default for guix environment proposed d

From: Konrad Hinsen
Subject: Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Date: Wed, 18 Dec 2019 10:43:46 +0100

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 <date> in <commit>".

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

   #!/usr/bin/env bash
   guix environment --container --ad-hoc gcc-toolchain <<EOF
   gcc pi.c -o pi
>> 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. 
> ;-)


> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]