On Sat, Jul 30, 2016 at 10:05 PM, Mathieu Lirzin <m...@gnu.org> wrote: > l...@gnu.org (Ludovic Courtès) writes: > >> Mathieu Lirzin <m...@gnu.org> skribis: >> >>> I have tested successfully with the following command on a foreign >>> system: >>> >>> guix environment --ad-hoc automake pkg-config guile guix libgcrypt sqlite >>> guile-sqlite3 >>> >>> Tell me if it works for you. >>> >>>> How about including a guix package definition then we can easily build >>>> it assuming "we" know how to do out-of-guix-tree package building :) >>> >>> It would indeed be nice to provide an easy way for Guix users to install >>> Cuirass. IMHO package definitions meant as a development build tool is >>> confusing and should be avoided. Nonetheless, I think it is useful to >>> document the previous 'guix environment ...' command in the README. >> >> What about providing a ‘guix.scm’ file that people could pass to ‘guix >> environment -l’ (instead of typing the long command above), and to ‘guix >> package -f’ (info "(guix) Invoking guix package")? > > 'guix environment -l' uses a package definition. To me this abstraction > doesn't fit well in a development context:
It *does* fit well. This use-case is why I wrote 'guix environment' in the first place. > - the origin hash doesn't make sense. You don't need one. Use local-file for the source field. > - packages already included in Guix have redundant description and synopsis. I don't understand what this means. > - package definitions rely on Guix internals. The package API rarely changes in practice. > In fact what 'guix.scm' contains feels more like a "debian" directory or > a "PACKAGE.spec" file on steroid because of the "guix environment -l" > feature which derives from it but doesn't appear as first class. > > An idea that I like better and is less invasive, would be to complement > bootstrap scripts with: > > ./bootstrap --with-guix > > This command would: > > - generate a guix-env script that wraps 'guix environment ...' if it > doesn't exist. > - Invoke ./guix-env > - Invoke autoreconf -vfi > > if the user wants to enter this environment Later it will have to invoke > './guix-env'. This just makes things more inconvenient and limits potential utility. You would lose the ability to tweak the dependency graph with custom package recipes. I do this frequently in my projects that use bleeding edge features of other software that may not even have an official release yet. Also, with a package file, Guix users can install the development snapshot with 'guix package -f' or simply build it with 'guix build -f'. > Some interesting things could be done beyond this, for example by using > per repository profiles that would save development environments. This > would allow developpers to easily use different setups. 'guix environment' already serves this purpose. I do want to extend 'guix environment' with a --save flag that will register the profile it generates as a GC root so that it can be saved for future sessions so that the environment doesn't need to be rebuilt every time the user upgrades Guix. Hopefully this clears things up. - Dave
