[bug#37478] [PATCH] Support canonical guix environment -l guix.scm.

[Thompson, David]

Hi,

On Mon, Dec 9, 2019 at 11:53 PM Brett Gilio <address@hidden> wrote:
>
> Hey all, where are we standing with this currently? I think there has
> been some recent revisions with how we are using the `-l` flag, and want
> to see if this still needs to some work. I am happy to offer my help.

I think it would be great if y'all could come to a consensus on a
canonical Guix environment file name (shortly after writing 'guix
environment' I started using 'guix.scm' files in the root of my
project repos in lieu of any convention) and, additionally, establish
whether that file evaluates to a package or to a manifest (or maybe it
could be either!)  I will change my project repos to conform to the
established convention.

To elaborate a bit on the choices, I've discovered there are pros and
cons to -l and -m and I've flip-flopped on which I liked better, but
today I find manifests to be the better option for the "I just cloned
a repo and want to build a dev environment" use-case.  Most of my
project environments are created via 'guix environment -l guix.scm'
and the contents of 'guix.scm' look something like this:

    (package
      (name "chickadee")
      (version "0.1")
      (source #f)
      (build-system gnu-build-system)
      (native-inputs
       `(("autoconf" ,autoconf)
         ("automake" ,automake)
         ("pkg-config" ,pkg-config)
         ("texinfo" ,texinfo)))
      (inputs
       `(("guile" ,target-guile)
         ("libvorbis" ,libvorbis)
         ("openal" ,openal)))
      (propagated-inputs
       `(("guile-opengl" ,guile-opengl)
         ("guile-sdl2" ,guile-sdl2)))
      (synopsis "Game development toolkit for Guile Scheme")
      (description "Chickadee is a game development toolkit for Guile
    Scheme.  It contains all of the basic components needed to develop
    2D/3D video games.")
      (home-page "https://dthompson.us/projects/chickadee.html";)
      (license gpl3+))

Initially I thought a package made sense because, in addition to being
used as the basis of a dev environment, I could build the same file as
part of a CI system or pre-release make target, but in practice I
can't really do that, thus the '(source #f)' bit and all the other
boilerplate like version, synopsis, description, and license fields to
satisfy the syntax rules.  It's also not a suitable package for
upstreaming to Guix later because building from git requires
additional dependencies that aren't needed when building from a
release tarball.  So, if I were to rewrite this file today, I think I
would just make a manifest instead.

Of course, Guix could also just eval the file, use package? and
manifest? predicates to see what it got, and act accordingly.  That
might be the best choice from a usability standpoint.

- Dave