Re: Guix Goals: One Hackable Developer Tool To Rule Them All

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Donnerstag, dem 13.10.2022 um 01:07 -0500 schrieb jgart:
> Hi Guixers,
> 
> What do you think if we were to implement "Guix Goals"?
> 
> The various language ecosystems have their own linters, formatters,
> typecheckers, repls, test runners, etc.
> 
> What if Guix could manage them all?
> 
> `guix lint` in a python project would run mypy.
> `guix lint` in a haskell project would run hlint.
> `guix lint` in an erlang project would run dialyzer.
> 
> `guix fmt` in a python project would run black.
> `guix fmt` in a haskell project would run ormolu.
> `guix fmt` in a erlang project would run erlfmt.
> 
> `guix repl` in a python project would run ptpython or some other
> configured repl.
> `guix repl` in a haskell project would run ghci.
> `guix repl` in a erlang project would run erl.
> 
> `guix test` in a python project would run pytest or unittest.
> `guix test` in a haskell project would run hunit.
> `guix test` in a erlang project would run eunit.
> 
> `guix run` in a python project could start a flask app listening on a
> particular port.
> `guix run` in a ruby project could start a puma server.
> `guix run` in a haskell project could run a pre-configured script or
> Main.hs
> `guix run` in a erlang project could start a cowboy server.
> 
> The idea would be to have Guix provide a configurable CLI wrapper
> subcommand around all language ecosystem developer tools. In other
> words it's the same Guixy thesis applied to developer tooling. I
> think this could take the Guix developer experience to the next
> level.
Completely unnecessary.  You can already do this with guix shell or gwl
if you prefer.

To elaborate, note that only the last variable in a file or manifest
needs to evaluate to a list of packages or manifest.  That is, you can
write a self-reading manifest/script wrapper relatively easy.

  #!/bin/sh
  exec guix shell -m "$0" -- guile -e main -s "$0" "$@" 
  !#

  (define (main args) ...)

  ...

  (specifications->manifest ...)

Of course, it'd be hell of a lot cleaner to separate manifest and
business logic, but who am I to stop you?

Cheers