"Thompson, David" <dthomps...@worcester.edu> writes: > 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.
Obviously I disagree. >> - the origin hash doesn't make sense. > > You don't need one. Use local-file for the source field. I would be happy to, however I vaguely remember trying this without success for Mcron. Do you have an example to provide? >> - 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. This is relative, IME packages moving across modules is not an exception. >> 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. Since this script is supposed to be wrapper around 'guix environment' I don't understand how it could limit anything 'guix environment' could do? > Also, with a package file, Guix users can install the development > snapshot with 'guix package -f' or simply build it with 'guix build > -f'. I am not sure what you mean by "development snapshot". If you an arbitrary timely chosen commit like what is done for Haunt: (origin (method git-fetch) (uri (git-reference (url "git://dthompson.us/haunt.git") (commit "f0a7c2b14a201448432d3564d851ee0686d5b1b1"))) (sha256 (base32 "1dnzsw18blhr8admw48zbl3ilz3iiqmb149i37y820h0imqfli0v")))) This is not useful for me. In most case I want 'guix build -f' to build the current commit from the local repository. If 'local-file' can work then this is fine, but I have never achieved the expected result. >> 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. That would be nice. > Hopefully this clears things up Maybe I am misinterpreting, but this read a bit patronizing. No need to say that if this is the case I don't appreciate much. -- Mathieu Lirzin