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

[Liliana Marie Prikler]

Am Sonntag, dem 16.10.2022 um 15:03 -0500 schrieb jgart:
> On Sun, 16 Oct 2022 20:50:47 +0200 Liliana Marie Prikler
> <liliana.prikler@gmail.com> wrote:
> 
> > makes your goal a somewhat stupid one if you don't actually specify
> > what it has to do on a per-project basis.
> 
> hi lilyp,
> 
> That's a bit harsh to say that my idea is "stupid" even in light of
> your qualifier.
> 
> If you read the previous thread you can see some of my proposals on a
> per language basis.
For context, the "goal" here refers to the individual goal, e.g.
"format", as specified in the initial post.  If it only ever covers the
most common case per programming language, that is a very stupid tool
indeed.

> There's absolutely no requirement for me to work out the whole
> solution just yet on this email thread or to offer per project
> details. I'm not at the stage of proposing per-project ideas. I'm
> just casually brainstorming with those colleagues who want to. If
> that's too stressful to do then anyone is free to opt out of the
> conversation. There's no need to call it "stupid". Instead, ask me to
> expound on it in a friendly way instead if something is not clear or
> not yet stated.
I am insisting on this notion of per-projectness, because it is key to
you understanding that you are indeed trying to construct a build
system.¹  Perhaps a very crude one, but a build system still.  Your
logical foundation are the following statements:

1. Every project written in L uses T for a specific task.
2. P is written in L.
3. Therefore P uses T for that task.

By constructing a per-task mapping of L ~> T, you can offer a unified
solution.

The truth, however, is more complicated.

1. Every sufficiently mature programming language L has at least one
task such that at least two tools T, T', T != T' are used in different
projects to achieve it.
2. There exist projects that are not limited to a single programming
language.

You can of course try to be smarter than that and try to figure out
which tools to invoke based on the existence and contents of certain
magic files, but note that at this point you're doing significantly
more work than in the declarative approach you rejected.

> > 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.    
> 
> If Guix channels don't give users enough
> freedom/hackability/extensibility
> to do what they want then maybe that's something that should be
> looked into. I would consider it a bug, and a limitation of the
> system. There should be enough trust in our community to allow users
> to hack channels the way they want and to contribute back to GNU Guix
> proper if they so choose.  Restrictions shouldn't be built into the
> system to prevent users from doing x, y, z with regards to extending
> it.  There should only be trust regarding extensibility. That's what
> made Guix stand out to me from the start. If that is not the case
> going forward then I will lose hope in Guix and would rather invest
> my time chasing that dream elsewhere. The extensibility thesis that
> Guix subscribes to (atleast to my understanding) involves trust in
> its users instead of giving them a limiting DSL and telling them what
> they are and are not allowed to do with it.
> 
> I came to GNU Guix because of this freedom of extensibility and these
> ideals that I perceived in channels and in the system as a whole.
> Contributing back to upstream not a limiting feature that is
> "designed in" to Guix in order to enforce it. I don't want to be
> limited that way. This trust has to exist if it wants to cooperate
> with the Schemer spirit.
I believe you're attacking a straw man here.  I'm not telling you that
you can't run with scissors, only that it'd be unwise if you did.

> > Refusing to use the tools your colleagues are using to instead hack
> > on your own is not a recipe for success.
> 
> I'm currently using my colleagues tools extensively. Not sure what
> you mean here...
This is calling back to the main motivation outlined in the initial
post; rather than invoking the linters, formatters, etc., you simply
wrap them in Guix.  It is almost always preferable to provide a
solution that works even for those who don't use Guix – for example a
"make indent" rule, etc.

Cheers

¹ Also note that pants, which seems to be a source of your inspiration,
describes itself as a build system.  Compare the already mentioned GWL
for a build system already based on Guix, albeit focused on scientific
workflows, and potato-make for a simplistic Guile-based build system.