Ludovic Courtès <l...@gnu.org> writes: > David Thompson <dthomps...@worcester.edu> skribis: > >> But all of that boilerplate is unnecessary since it's not possible to >> actually build the package successfully without a proper hash of the >> source AFAICT. Really, I would rather just use a simple list of >> packages: >> >> (list autoconf automake guile-2.0 guile-json libgcrypt) > > What about adding a case for the handling of ‘-l’ such that, if the file > evaluates to a list of packages, it does what you suggest?
I'm hesitant to do that, because I would also like for a list of packages to be usable for building the environment as it's done currently. Only allowing a single package in a file is a limitation right now. >> I propose adding a new flag that indicates whether we want the packages >> themselves or their inputs in the environment. If we assume that the >> default behavior is to include the packages themselves, a --inputs flag >> could indicate to use the package(s) inputs instead: >> >> guix environment --inputs emacs > > That makes sense. > > In terms of UI, what about rather something keeping an interface close > to that of ‘guix package’: > > guix environment -i guile guile-sdl > # semantically equivalent to ‘guix package -i guile guile-sdl’ So without the -i switch, it would behave as it does now? Okay, but I guess I would prefer to optimize for the common case, which in my case would be having -i on by default. > Now that I think of it, we could even move -E to ‘guix package’ itself: > that would make it easy to create a scratch environment based on an > existing profile. I'm a bit confused about that. Are you suggesting we merge 'guix environment' into 'guix package'? -- David Thompson Web Developer - Free Software Foundation - http://fsf.org GPG Key: 0FF1D807 Support the FSF: https://fsf.org/donate
