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

[pinoaffe]

Hi,

I think that (if done well) this would greatly simplify my workflow in
many software projects, so I think it's a good idea.

In the rest of my email, I more or less assume that there is a
one-to-one correspondence between software projects and guix packages,
even though this is clearly not the case.  I nonetheless make this
assumption since it is the case (or can be made the case) for many of
the software projects on which one might want to work using guix.

jgart <jgart@dismail.de> writes:
> 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.

These would require some sort of configurability, since most
languages/projects have not just one linter.  Even if there's a
"monopoly" there might be different settings/versions of said linter.

Do you propose that such configuration is added to packages?  Or should
this go somewhere else?

Furthermore, in many projects there are various different languages at
once (e.g., a python webapp with client-side javascript and css), so it
would probably be useful to mirror the build-phases approach in guix
packaging.  It might even be possible to set up (somewhat) sane defaults
based on the build-system used by the local project.

> `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.

My comments regarding linters apply here as well

> `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.

This should be fairly easy to implement, assuming that there is just one
repl associated to each project one might want to use this command with.
It should (imo) be possible to configure/pass arguments to the repl on a
per-project basis and whenever you run `guix repl`

> `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.

Should I read this as a proposal to add an extra command to build (and
test) the local project's guix package, or do you propose to make this
do something different?  Because I'm not sure the latter would be a good
idea, if there is a need to do testing in some other way than currently
possible I'd think it would be more valuable (and more clean) to extend
the current testing facilities to incorporate this.

> `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.

I'm not sure how widely this may be applicable, since many projects or
packages don't have just one way to run them, they may even contain
several different executables or modules.

> 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.

Kind regards,
pinoaffe