Le 2015-08-19 15:04, Thompson, David a écrit :
On Wed, Aug 19, 2015 at 4:27 AM, Amirouche Boubekki
<[email protected]> wrote:
Le 2015-08-09 17:59, David Thompson a écrit :
In my personal projects, I keep a 'package.scm' file in the root of
the
source tree for use with 'guix environment -l'. However, it's also
handy to install that package by using 'guix package -e':
guix package -e '(primitive-load "package.scm")'
This patch adds a shorthand for this:
guix package -f package.scm
What about dispatch `guix package -i` depending on the argument. In
principle there will be no "*.scm$" packages so the above could be
guix package -i package.scm
The idea behind that is to keep the number of command to minimum. In
this
case, IMO, it makes sens to merge both logic inside the same UI.
That won't work because it creates ambiguities in the package spec
syntax.
Thanks.
How can one tell if a package spec or a file name was passed
with 100% accuracy?
Honestly I have the feeling that you are pushing your idea more than
trying to make things better.
- Adding the `-f` modifier won't help make guix package command easy to
the mind.
- Especially since the command it will replace is simple
- The command targets developpers and is only useful in the context of
building project from sources which are not released. It can go inside a
Makefile.
For this reason I don't like it being inside guix.
You can't, and we'd have to use a heuristic that
would surely fail in some awful way for someone. It's best for this
to be a separate argument.
You know you are wrong. You can simply ban packages which ends with .scm
which is not too difficult to do and is already possible with current
packages.
My opinion, is that instead of adding options/modifiers to "guix
package", it should be split into "guix package install", "guix package
search", "guix package show" and "guix package generation". It might not
be obvious and is afaik not a cli layout that is widespread but it will
greatly help people get their hands on guix.
I get lost and don't remember all the apt-foo commands and what they are
supposed to do. Using this scheme will keep each subcommand --help (or
just help) more readable.
