dannymi on Guix for Development

For step 5:

guix install foo --with-source=foo=yourfixedversion_src.tar.gz

Or:

guix install foo --with-patch=foo=yourpatch.patch

(note: usually packages are installed as regular user into your user profile)

See also section "Package Transformation Options" in "info guix".

For step 6, send a mail with the patch to the package definition (in an existing scm file in https://git.savannah.gnu.org/git/guix.git ) to the guix-devel mailing list. But whatever you did manually to get yourfixedversion_src.tar.gz you now should automate by programming the patching process in Scheme instead--editing a guix checkout (usually just to add: (add-after 'unpack 'patch-problematic-stuff-4711 (lambda _ (substitute* "somefile" (("regex1") "replacement"))))). For more complicated fixes, add a patch to the guix checkout and make Guix use it in Scheme (and contribute it to the actual foo upstream project--which we usually do anyway).

See section "Contributing" in "info guix".

Further automation welcome-- and probably not that difficult to add. Just keep in mind that each package build is in its own container (it's kinda like Docker would be)--so no mixing text editor and building and weird user-defined pauses (for example there is no text editor in the build container).

dan-robertson 3y

I guess I wish that the custom install were as easy as guix shell (and that it would also do sensible things like recompiling dependencies if you modified a library). But maybe it’s actually hard to do for reasons I haven’t thought about.

dannymi 3y

I guess I wish that the custom install were as easy as guix shell (and that it would also do sensible things like recompiling dependencies if you modified a library).

The reason for the seemingly duplicate "foo" in the "--with-" options is that those "--with-" can apply to dependencies if you specify the right package there (so in the example, something else than "foo"--like something foo depends on). In that case it will recompile everything that needs recompiling.

But maybe it’s actually hard to do for reasons I haven’t thought about.

It can easily be that we all made our own workarounds and so while it would be easy to add a nice frontend, nobody has a need.

So if you do think of a nice way, please try to do it.

For example we have some bias for emacs: inside emacs the guix development is very comfortable (we have and ship our own extensions for emacs). But that doesn't help you if you are not an emacs user.

The Guix package repo is a monorepo (see below)--all those packages have to work (and be tested) together.

From time to time I do think it would be nice to reduce barrier of entry by automating existing package editing inside a shell script we could ship:

  if [ ! -d guix ]
  then
    git clone --depth=1 https://git.savannah.gnu.org/git/guix.git guix
  else
    (cd guix && git pull --rebase)
  fi \
  && cd guix
  && guix shell -C -D guix -- ./bootstrap \
  && guix shell -C -D guix -- ./configure --localstatedir=/var --disable-daemon \
  && guix shell -C -D guix -- make -j5 \
  && ./pre-inst-env guix edit foo \
  && git add gnu/packages/*.scm

(the guix edit is NOT in the guix shell environment, therefore you have an editor)

... but so far it never makes it out of my head to an actual script shipped with guix :(

If we did make it--what would the package it would be in be called? Or should it be a subcommand of the "guix" command?

That said, if you want to make your own NEW packages, that's easy and well-supported. You can put a guix.scm whereever you like and lots of guix stuff will pick it up automatically.

rendaw 3y

You also need to subscribe to the mailing list or your emails will be ignored.

yyyk2 3y

That's not true. I've never subscribed to the mailing list and all patches I've sent were applied.

Comments