Re: Help defining a trivial package.

[Timothy Sample]

Hello!

I’m glad the Python code was helpful.  :)  I’ve commented on some of
your other points below.

"Pierre-Henry F." <address@hidden> writes:

> Development:
>
>     $ guix environment --manifest=./guix/manifest.scm --pure --container
>     $ # Develop things. Add dependencies at will in manifest.scm
>
>
> Build release:
>
>     $ ./deployment/make_release
>     Built release: release_4.tar.lz
>
>
> Deployment:
>
>     $ guix build --keep-failed --verbosity=2 --file=./blog.scm
>     …
>     /gnu/store/…-blog-4
>
>
> Test:
>
>     $ /gnu/store/…-blog-4/bin/program
>     Hello world!
>
>
> What would be very helpful:
>
>     - Define blog.scm such that ~$ guix environment blog~ has the same effect 
> as
>       ~$ guix environment --manifest=./guix/manifest.scm --pure --container~

This really depends on what’s in “manifest.scm”.  If it contains tools
for building the blog, it would be same, but I take it that
“manifest.scm” has tools for hacking on the blog, too (like editors or
whatever).  In this case, it’s actually a feature that they’re separate.
It keeps the build and runtime time dependencies apart from the
development dependencies.  You can always combine the two, so that
“manifest.scm” only has to contain the extra stuff:

    guix environment --pure --container \
        -l blog.scm --ad-hoc -m manifest.scm

This will pull in all the build and runtime dependencies of the package
defined in “blog.scm” plus all the extra tools from “manifest.scm”.

>     - Define a package ~blog_executable.scm~ derived from ~blog.scm~ such that
>       ~$ guix package -i blog_executable~ has the same effect has
>       ~$ guix build --file=./blog_v2.scm~, but actually install the thing.
>
>       ~blog_executable.scm~ is essentially ~blog.scm~ but stripped down to 
> the bare
>       minimum to get the executable working.

This is definitely possible.  All you need to do is make sure that the
package defined in “blog_executable.scm” has its source field set
properly.  What I’ve done in the past is use Guile-Git to use all of the
files that Git knows about as the source of the package.  This makes
sure transient build artifacts are not included (since they are likely
ignored by Git).  If you like, take a look at this file:

    https://git.savannah.nongnu.org/cgit/gash.git/tree/guix.scm

It is the main Guix package definition that I use when developing Gash
(a shell written in Guile that I maintain).  If you clone the repo, you
can run “guix package -f guix.scm” to build and install Gash from the
latest Git sources (the ones you just cloned).  There are two things to
note, though.  First, if you use it for testing the build, it can get
confusing as to which files are included: is it files in the working
tree, files in the index, or files from the latest commit?  I honestly
get confused and miss things all the time!  The second thing is that
since I wrote that package definition, Guix got a procedure called
“git-predicate” in “(guix git-download)” that does basically the same
thing as my “make-select”.  I recommend using the Guix procedure if
possible, I just haven’t looked into it yet.  :)

> If all the above is true then I hope that we (multiple devs) can have the 
> guarantee
> to have the same dev environment and a simple deployment build that's just the
> development environment minus dev dependencies.
>
> With these things in place, a deployment should be deterministic and as 
> simple as a:
>
>     $ guix package -i blog_executable
>
>
> To sum up, here are the questions I try to answer:
>
>     - How to define ~blog.scm~ such that ~$ guix environment blog~ works?
>     - How to define ~blog_executable.scm~ such that ~$ guix package -i 
> blog_executable~ works?

I hope what I wrote above helps answer these questions!


-- Tim