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: - the origin hash doesn't make sense. - packages already included in Guix have redundant description and synopsis. - package definitions rely on Guix internals. 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'. 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. WDYT? -- Mathieu Lirzin
