Hi,

ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Chris Marusich <cmmarusich@gmail.com> skribis:
>
>> Here's a patch to address the following issue ('guix environment guix
>> doesn't provide guix dependencies'):
>>
>> https://lists.gnu.org/archive/html/guix-devel/2016-09/msg02118.html
>
> Thanks for looking into it!
>
>> I signed the commit with my GPG key, but it seems that 'git
>> format-patch' doesn't include the signature.  If you know how to make it
>> include the signature, please let me know!
>
> I think it can’t do that.  So in practice whoever pushes signs on your
> behalf.

OK.  That's what I suspected!

>> From 3fa2bc4f0d11fc695bfab9b85981228c1a88e007 Mon Sep 17 00:00:00 2001
>> From: Chris Marusich <cmmarusich@gmail.com>
>> Date: Sun, 2 Oct 2016 13:00:34 -0700
>> Subject: [PATCH] gnu: Make "guix-devel" a public variable in
>>  package-management.scm
>>
>> This provides an obvious and easy way to use Guix to set up an environment for
>> building Guix from a Git checkout.
>>
>> * gnu/packages/package-management.scm (guix-devel): Make it public and give it
>>   an appropriate name, synopsis, and description.  Change the generated
>>   version string to be even shorter so that the tests can actually run.
>>   Update all documentation to refer to "guix" when talking about the release
>>   version, and "guix-devel" when talking about the development version.
>
> [...]
>
>> -(define guix-devel
>> +(define-public guix-devel
>>    ;; Development version of Guix.
>>    ;;
>>    ;; Note: use a very short commit id; with a longer one, the limit on
>>    ;; hash-bang lines would be exceeded while running the tests.
>>    (let ((commit "4420940f20a2f36f29519f686bca7b85be6be5c9"))
>>      (package (inherit guix-0.11.0)
>> -      (version (string-append "0.11.0-1." (string-take commit 4)))
>> +      (name "guix-devel")
>> +      (version (string-take commit 8))
>>        (source (origin
>>                  (method git-fetch)
>>                  (uri (git-reference
>> @@ -251,7 +252,16 @@ the Nix package manager.")
>>           ("texinfo" ,texinfo)
>>           ("graphviz" ,graphviz)
>>           ("help2man" ,help2man)
>> -         ,@(package-native-inputs guix-0.11.0))))))
>> +         ,@(package-native-inputs guix-0.11.0)))
>> +      (synopsis "Development version of GNU Guix")
>> +      (description "GNU Guix is a functional package manager for the GNU
>> +system, and is also a distribution thereof.  It includes a virtual machine
>> +image.  Besides the usual package management features, it also supports
>> +transactional upgrades and roll-backs, per-user profiles, and much more.  It
>> +is based on the Nix package manager.  This is a development version which is
>> +built from a recent commit in the project's Git repository.  It provides
>> +additional dependencies that are not normally required for building the
>> +release version, such as GNU Autoconf."))))
>>  
>>  (define-public guix guix-devel)
>
> There’s the problem that the ‘guix-devel’ variable above is also the
> Guix package that we currently use, and thus it should be called “guix”,
> not “guix-devel”.
>
> So what about something along these lines:
>
>
> diff --git a/gnu/packages/package-management.scm b/gnu/packages/package-management.scm
> index 70a6a49..8a77c40 100644
> --- a/gnu/packages/package-management.scm
> +++ b/gnu/packages/package-management.scm
> @@ -255,6 +255,18 @@ the Nix package manager.")
>  
>  (define-public guix guix-devel)
>  
> +(define-public guix-for-environment
> +  ;; We provide this pseudo-package just to allow people to run:
> +  ;;   guix environment guix-devel
> +  ;; to reliably get the development environment for Guix (using 'guix' for
> +  ;; this purpose does not work when 'guix' points to the built-from-tarball
> +  ;; package rather than to the built-from-checkout package.)
> +  (package
> +    (inherit guix-devel)
> +    (name "guix-devel")
> +    (source #f)                                   ;not meant to be built
> +    (supported-systems '())))
> +
>  (define (source-file? file stat)
>    "Return true if FILE is likely a source file, false if it is a typical
>  generated file."
>
>
> ?
>
> If that’s fine with you, could you incorporate it in your patch?

Sounds good to me.  I've attached the updated patch to this email and
mentioned you as co-author.  The new package fails to build with a
cryptic error, but since it isn't meant to be built, that seems OK.

What is the purpose of temporarily changing the "guix" variable to refer
to the release package (as in commit 4420940f)?  Because it usually
refers to the development version, wouldn't it be better to make the
"guix" variable ALWAYS refer to the development version?  It isn't clear
to me why we need to temporarily change this variable to refer to the
release version.

> Minor comment: it’s useful to provide a specialized synopsis like you
> did, but I think it’s better to leave the description unchanged rather
> than duplicate it almost identical.

That's fine with me, too.  Thank you for your review!

-- 
Chris