[Top][All Lists]

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

Re: Development shell for diffutils does not appear to work - what am I

From: Tobias Geerinckx-Rice
Subject: Re: Development shell for diffutils does not appear to work - what am I doing wrong?
Date: Wed, 27 Sep 2023 14:43:17 +0200

Hi (again) Dan,

On 2023-09-27 12:58, Daniel Littlewood wrote:
--development argument. The docs say
Cause guix shell to include in the environment the dependencies of the following package rather than the package itself.
and I took "dependencies" to mean "build dependencies".


But perhaps it just means the runtime ones?

I'm not aware of an option for this even if you wanted to.

So as you say, you could download the release tarball of diffutils and
be able to run it, but not necessarily to build it from the source.

The release tarball *is* the source — of the ‘diffutils’ package. The only additional native (‘build’) input needed to build it is ‘perl’, which is also provided by ‘guix shell -D diffutils’.

I wonder why the flag is called "development" when it doesn't allow
you to develop the package.

It's true that it doesn't provide a full-featured ‘development environment’, including someone's favourite editor, etc. However, I don't think it's poorly named. Language is just hard. Calling it ‘--build’ would confuse people who think Guix has a notion of ‘build dependencies’, of which there are already too many.

The point of ‘guix shell -D’ is to provide an environment where you can build a package, as packaged in Guix, from source, as packaged in Guix. Hence:

- *All* build system (‘implicit’) inputs such as a compiler/toolchain, GNU coreutils, etc.
  - *All* native package inputs, if any (in diffutils' case: perl).

This is all you need to build diffutils as packaged:

If you BYO source, different from that used by Guix, you'll have to BYO extra development inputs it requires.

Alternatively, you could rewrite Guix's diffutils package to build from Git. You'd then add extra packages like autoconf, automake, etc., to native-inputs, which would then be picked up by ‘guix package -D diffutils’.

Perhaps it refers to developing guix?

When used in ‘guix shell -D guix’, maybe… :-)

Perhaps there is a similar expression for importing everything in a
specific build system?

That's what ‘-D’ does. It's the assumption that autotools are part of any build-system that's muddying the waters here. AFAIK they are not.

Grep Guix: if a package bootstraps ./configure and friends from scratch, it is expected to declare autoconf & automake (and probably more) as inputs. Diffutils doesn't. If you do, that's fine, but then you're operating outside of the Guix diffutils package and need to add your own extra inputs on the command line.

Since I was mixed up between building and installing, I also wonder
whether this is what `guix build` is for. Or, equally, if I copy the
definition of diffutils in base.scm and then do `guix shell -f
my-diffutils.scm` maybe it will build itself? It certainly seems to
have all the necessary information to do so.

That's identical to ‘guix build diffutils’, no?

Kind regards,


Sent from a Web browser.  Excuse or enjoy my brevity.

reply via email to

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