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

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

Am Sonntag, dem 16.10.2022 um 12:54 -0500 schrieb jgart:
> On Sun, 16 Oct 2022 15:11:38 +0200 Liliana Marie Prikler
> <liliana.prikler@gmail.com> wrote:
> > Am Donnerstag, dem 13.10.2022 um 01:07 -0500 schrieb jgart:
> >   #!/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?
> 
> Hi lilyp,
> 
> Yup, the latter is what I'm proposing instead of implementing a goal
> for each lang à"ala carte" as a script for each project.
This à la carte approach will definitely break down in polyglot
applications – hence needing a more generic solution for the generic
case – and even when there's just one language, the fact that multiple
compilers, linters, etc. exist and people are very opinionated on which
ones to use with which options makes your goal a somewhat stupid one if
you don't actually specify what it has to do on a per-project basis.

> That would be like implementing part of a build-system everytime
> when needed like we currently do when we needing to run pytest
> instead their being first class support like was being worked on in:
> https://github.com/guix-mirror/guix/tree/wip-python-pep517.
> 
> I'd like for "goals" to have first class support like guix home
> configs, etc. do. But thanks for reminding us that we can just
> implement it directly as needed in a script for each project. That's
> a testament to the extensibility of Guix!
I don't think it'd be that.  Note that you have the full power of
Guix/Guile at your disposal, so you can encapsulate much of it in
channels.  Is it a good idea to do so?  Hell, no.  Refusing to use the
tools your colleagues are using to instead hack on your own is not a
recipe for success.  There are good reasons why generic build systems
like make and ninja are more widely adopted than their language-focused
counterparts.  You're not doing anyone a favour here by forcing them to
adopt a solution that has parentheses.

Instead of aiming for world domination, you should try writing a tool
that helps folks collaborate.  Adding a guix.scm alone already does
wonders in this regard, but if you really want to go beyond, you could
define a set of workflows with gwl or fall back to ye good olde make
and ninja.  And if you don't like either, there's potato-make [1].

Cheers

[1] https://github.com/spk121/potato-make