Guix and the developer ecosystem

Guix and the developer ecosystem

[Distopico]

Hi, I'm quite new in Guix, I have been using it for 6 months now and I
love it, but for development I have not been able to use it as much as I
would like.

The current programming languages are made up of three 4 parts:

1. The languages itself
2. Language-server
3. The language packages
4. Language tools (formatter, linter)

It is possible to development without a language server, but many
projects now require special formatting or running linter tools,
etc. These are things that are somewhat basic in a certain way.

In terms of programming languages, I have found almost all the ones I
needed, with the exception of Kotlin.

Regarding language servers, most of the ones I needed either haven't
worked for me or don't exist. For example, Rust, Haskell, and Elm have
few tools available, and even though I mainly program in Rust and
Haskell, and lately, I've been getting into Guile, I also have old
projects in Kotlin, for instance, or sometimes I like try other
languages when `guix shell` is awesome.

So, sometimes I wish to do...

```
guix shell ghc haskell-language-server hlint
```

In that case, the language server isn't available. Another example:

```
guix shell rust@1.67.1 rust-analizer rust-clippy
```

In that case, rust-analyzer won't be compatible with that version of
Rust, and the version of rust-analyzer is broken (I sent a patch fixing
it).

In some languages like Haskell and GoLang, the language server depends a
lot on the version it was compiled with. For example, I tried gopls,
which is available in Guix, but it was built with Go 17 and is not
compatible it.

So, in many cases, I haven't been able to fully integrate Guix into my
development workflow. I had to look for alternative ways outside Guix,
like Nix.

I appreciate the simplicity of Guix, but let's say that Nix has a
developer-oriented approach and has become very popular among
programmers. Many projects now include default configurations for Nix in
their repositories.

Another issue is that if I wanted to bring Guix into the development
workflow in a team, there would be the limitation of the OS. While I
promote free software in working groups, not everyone uses the same OS -
some use GNU/Linux, some use Mac, etc. I think this is also part of the
reason why Nix has succeeded in development environments.

All this text is provided some context for two simple questions:

1. Are there plans in the future to improve integration between
development tools? For example, having haskell-language-server for
ghc@9.x and another one for ghc@8.x, or something similar to the
overwrite feature in Nix flake?

2. Do you see developers as a potential target audience for Guix, or is
it mainly focused on HPC (High-Performance Computing)?

I have started contributing to packages that I believe could be useful,
and I like to contributing to teams such as Haskell or Rust. However,
there are other topics, such as compiler and tools compatibility, where
I'm not entirely clear about the direction that has been planned.

And apologies for the lengthy text.

Re: Guix and the developer ecosystem

[Liliana Marie Prikler]

Hi Distopico

Am Mittwoch, dem 26.07.2023 um 19:29 -0500 schrieb Distopico:
> 
> Hi, I'm quite new in Guix, I have been using it for 6 months now and
> I love it, but for development I have not been able to use it as much
> as I would like.
"Development" is a loaded term that is understood differently by
different groups of people.  I personally write software in dialects of
C and Lisp (yes, even Java if I must), sometimes Python, and most of
the time Guix at the very least suffices for doing so, if it doesn't
excel.  Obviously, the holy grail here is a reasonable build system
based on GNU tools, CMake or Meson, that "modern programming languages"
often don't want to employ.

> The current programming languages are made up of three [or four]
> parts:
> 
> 1. The languages itself
> 2. Language-server
> 3. The language packages
> 4. Language tools (formatter, linter)
> 
> It is possible to development without a language server, but many
> projects now require special formatting or running linter tools,
> etc. These are things that are somewhat basic in a certain way.
But as with all necessities, just because they're "basic" doesn't mean
that they're also available to the masses.  There are several
programming languages, where even getting to a compiler is impossible,
let alone the other three items on your list.  See [1] on why that's a
bad idea.

> In terms of programming languages, I have found almost all the ones I
> needed, with the exception of Kotlin.
[2]

> Regarding language servers, most of the ones I needed either haven't
> worked for me or don't exist. For example, Rust, Haskell, and Elm
> have few tools available
I wonder what all of those have in common.  🤔️

> [E]ven though I mainly program in Rust and Haskell, and lately, I've
> been getting into Guile, I also have old projects in Kotlin, for
> instance, or sometimes I like try other languages when `guix shell`
> is awesome.
> 
> So, sometimes I wish to do...
> 
> ```
> guix shell ghc haskell-language-server hlint
> ```
> 
> In that case, the language server isn't available. Another example:
I mean, you could try packaging it, assuming it has a reasonable
dependency graph.  Okay, you can stop laughing now.

> ```
> guix shell rust@1.67.1 rust-analizer rust-clippy
> ```
> 
> In that case, rust-analyzer won't be compatible with that version of
> Rust, and the version of rust-analyzer is broken (I sent a patch
> fixing it).
--with-input to the rescue.

> In some languages like Haskell and GoLang, the language server
> depends a lot on the version it was compiled with. For example, I
> tried gopls, which is available in Guix, but it was built with Go 17
> and is not compatible it.
--with-input?

> So, in many cases, I haven't been able to fully integrate Guix into
> my development workflow. I had to look for alternative ways outside
> Guix, like Nix.
I mean, with ecosystems that insist on using their tools for packaging
and nothing else, even just having it in Nix is already a step up.  But
at the same time Nix cuts corners that Guix cutsn't, and I'm pretty
sure that these tools fall right into that category.

> I appreciate the simplicity of Guix, but let's say that Nix has a
> developer-oriented approach and has become very popular among
> programmers. Many projects now include default configurations for Nix
> in their repositories.
Certainly, Nix enjoys clout, but there's nothing to stop you from
committing a guix.scm to your favourite project.  Case in point, I
recently contributed to one such project on Github (via mail to the
devs, of course).

> Another issue is that if I wanted to bring Guix into the development
> workflow in a team, there would be the limitation of the OS. While I
> promote free software in working groups, not everyone uses the same
> OS - some use GNU/Linux, some use Mac, etc. I think this is also part
> of the reason why Nix has succeeded in development environments.
If you have the metal to spare, why not help us ingest some Asahi Linux
patches?

> All this text is provided some context for two simple questions:
> 
> 1. Are there plans in the future to improve integration between
> development tools? For example, having haskell-language-server for
> ghc@9.x and another one for ghc@8.x, or something similar to the
> overwrite feature in Nix flake?
You mean other than --with-input?  Well, you can pray for the upcoming
USE flag light parameterized packages to become just that, though I
personally hope they don't, as there are more interesting applications.

> 2. Do you see developers as a potential target audience for Guix, or
> is it mainly focused on HPC (High-Performance Computing)?
Well, the "developers" Guix sees as target audience typically refer to
themselves as hackers and don't think of themselves as an elite that
ought to be given exclusive access to their tools, but rather as a
vanguard party that wishes to make them available to all.

High performance computing is one application in which Guix makes a lot
of sense, but there are others ranging from academic over less academic
to everyday computing, games, and even running stress on your CPU, GPU,
and what other PUs you can nowadays put into hardware to make number go
up while the world is literally on fire.

> I have started contributing to packages that I believe could be
> useful, and I like to contributing to teams such as Haskell or Rust.
> However, there are other topics, such as compiler and tools
> compatibility, where I'm not entirely clear about the direction that
> has been planned.
There is only one direction, and that is forward.

Cheers

[1] https://bootstrappable.org/
[2] https://bootstrappable.org/projects/java-tools.html

Re: Guix and the developer ecosystem

[Distopico]

[-- Attachment #1: Type: text/plain, Size: 8140 bytes --]


On 2023-07-29, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

> Hi Distopico
>
> Am Mittwoch, dem 26.07.2023 um 19:29 -0500 schrieb Distopico:
>> 
>> Hi, I'm quite new in Guix, I have been using it for 6 months now and
>> I love it, but for development I have not been able to use it as much
>> as I would like.
> "Development" is a loaded term that is understood differently by
> different groups of people.  I personally write software in dialects of
> C and Lisp (yes, even Java if I must), sometimes Python, and most of
> the time Guix at the very least suffices for doing so, if it doesn't
> excel.  Obviously, the holy grail here is a reasonable build system
> based on GNU tools, CMake or Meson, that "modern programming languages"
> often don't want to employ.
>

Hi, thank you for your response, well When I say "developer ecosystem,"
I'm referring to a significant variety of languages, whether new or not,
to meet the development needs in different languages compatible with
free-software software. Otherwise, it would be a development environment
limited to C, Python, and a few others, which should be clarified to
users to avoid creating false expectations. By "horizon" or the future
vision of the project, I mean the overall outlook concerning this aspect.

I can't say that Haskell falls under the category of "modern," but it
has been progressively "modernizing," adapting to the implications,
whether good or bad. Javascript is definitely not new, and TypeScript is
another example that is not new either.

>> The current programming languages are made up of three [or four]
>> parts:
>> 
>> 1. The languages itself
>> 2. Language-server
>> 3. The language packages
>> 4. Language tools (formatter, linter)
>> 
>> It is possible to development without a language server, but many
>> projects now require special formatting or running linter tools,
>> etc. These are things that are somewhat basic in a certain way.
> But as with all necessities, just because they're "basic" doesn't mean
> that they're also available to the masses.  There are several
> programming languages, where even getting to a compiler is impossible,
> let alone the other three items on your list.  See [1] on why that's a
> bad idea.
>

Does Guix have a plan to address this in the future or a workaround? I
believe that in the future, this issue will become even more common,
just as more languages have their own package managers, which are partly
responsible for this huge dependency tree.

>> In terms of programming languages, I have found almost all the ones I
>> needed, with the exception of Kotlin.
> [2]
>
Thank, good to known that, just curious why/how nix have it.

>> Regarding language servers, most of the ones I needed either haven't
>> worked for me or don't exist. For example, Rust, Haskell, and Elm
>> have few tools available
> I wonder what all of those have in common.  🤔️
>
>> [E]ven though I mainly program in Rust and Haskell, and lately, I've
>> been getting into Guile, I also have old projects in Kotlin, for
>> instance, or sometimes I like try other languages when `guix shell`
>> is awesome.
>> 
>> So, sometimes I wish to do...
>> 
>> ```
>> guix shell ghc haskell-language-server hlint
>> ```
>> 
>> In that case, the language server isn't available. Another example:
> I mean, you could try packaging it, assuming it has a reasonable
> dependency graph.  Okay, you can stop laughing now.
>

You are absolutely right. As I mentioned before, the ever-increasing
huge dependency tree is becoming more common in various programming
languages due to the convenience of package managers. It is essential to
have a plan on how to address these situations to ensure the long-term
sustainability and maintainability of projects. Without a plan, it might
be better not to embark on such a journey, as managing complex
dependency chains can lead to numerous challenges and issues in the
future. Projects like Guix need to actively consider strategies to
handle and mitigate these complexities effectively to ensure a smooth
and sustainable development process.

>> ```
>> guix shell rust@1.67.1 rust-analizer rust-clippy
>> ```
>> 
>> In that case, rust-analyzer won't be compatible with that version of
>> Rust, and the version of rust-analyzer is broken (I sent a patch
>> fixing it).
> --with-input to the rescue.
>

Nice, I'll try it, thank you

>> I appreciate the simplicity of Guix, but let's say that Nix has a
>> developer-oriented approach and has become very popular among
>> programmers. Many projects now include default configurations for Nix
>> in their repositories.
> Certainly, Nix enjoys clout, but there's nothing to stop you from
> committing a guix.scm to your favourite project.  Case in point, I
> recently contributed to one such project on Github (via mail to the
> devs, of course).
>

Well, what holds me back is that many dependencies are missing, such as
the basic ones I mentioned, making it impossible to use Guix in many
cases. Others have non-ideal solutions, like one suggested in Matrix:
`guix shell --container --emulate-fhs' + downloading the rustup script
and installing it just to use clippy (the Rust linter). So, it's not
feasible to include that in the project due to current limitations.

>> Another issue is that if I wanted to bring Guix into the development
>> workflow in a team, there would be the limitation of the OS. While I
>> promote free software in working groups, not everyone uses the same
>> OS - some use GNU/Linux, some use Mac, etc. I think this is also part
>> of the reason why Nix has succeeded in development environments.
> If you have the metal to spare, why not help us ingest some Asahi Linux
> patches?
>

Well, I think is not a real solution, a lot of time the people with
those mac are from the companies and you are not able to change the OS,
or sometimes you work as a freelancer in a company and other people use
Mac and they don't wan to change just becase an contractor have the idea
of use Guix.

>> All this text is provided some context for two simple questions:
>> 
>> 1. Are there plans in the future to improve integration between
>> development tools? For example, having haskell-language-server for
>> ghc@9.x and another one for ghc@8.x, or something similar to the
>> overwrite feature in Nix flake?
> You mean other than --with-input?  Well, you can pray for the upcoming
> USE flag light parameterized packages to become just that, though I
> personally hope they don't, as there are more interesting applications.
>

Maybe this will be the solution:
https://blog.lispy.tech/parameterized-packages-the-second-update.html

>> 2. Do you see developers as a potential target audience for Guix, or
>> is it mainly focused on HPC (High-Performance Computing)?
> Well, the "developers" Guix sees as target audience typically refer to
> themselves as hackers and don't think of themselves as an elite that
> ought to be given exclusive access to their tools, but rather as a
> vanguard party that wishes to make them available to all.
>
> High performance computing is one application in which Guix makes a lot
> of sense, but there are others ranging from academic over less academic
> to everyday computing, games, and even running stress on your CPU, GPU,
> and what other PUs you can nowadays put into hardware to make number go
> up while the world is literally on fire.
>

Well, is someone want to hack with Rust/Haskell using Guix is not
possible, They may end up taking alternative paths like in my case, or a
mix of using Guix in some areas and not in others.

>> I have started contributing to packages that I believe could be
>> useful, and I like to contributing to teams such as Haskell or Rust.
>> However, there are other topics, such as compiler and tools
>> compatibility, where I'm not entirely clear about the direction that
>> has been planned.
> There is only one direction, and that is forward.
>

For sure, thank you.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]

Re: Guix and the developer ecosystem

[Liliana Marie Prikler]

Hi Distopico,

Am Freitag, dem 04.08.2023 um 20:11 -0500 schrieb Distopico:
> 
> On 2023-07-29, Liliana Marie Prikler <liliana.prikler@gmail.com>
> wrote:
> 
> > Hi Distopico
> > 
> > Am Mittwoch, dem 26.07.2023 um 19:29 -0500 schrieb Distopico:
> > > 
> > > Hi, I'm quite new in Guix, I have been using it for 6 months now
> > > and I love it, but for development I have not been able to use it
> > > as much as I would like.
> > "Development" is a loaded term that is understood differently by
> > different groups of people.  I personally write software in
> > dialects of C and Lisp (yes, even Java if I must), sometimes
> > Python, and most of the time Guix at the very least suffices for
> > doing so, if it doesn't excel.  Obviously, the holy grail here is a
> > reasonable build system based on GNU tools, CMake or Meson, that
> > "modern programming languages" often don't want to employ.
> > 
> 
> Hi, thank you for your response, well When I say "developer
> ecosystem," I'm referring to a significant variety of languages,
> whether new or not, to meet the development needs in different
> languages compatible with free-software software. 
I mean, even if you object in the paragraphs below, Guix already covers
a significant variety of languages, probably more so than other system
package managers and in any case more so than language-specific ones.  

> Otherwise, it would be a development environment limited to C,
> Python, and a few others, which should be clarified to users to avoid
> creating false expectations. By "horizon" or the future vision of the
> project, I mean the overall outlook concerning this aspect.
Well, as it turns out with generic solutions to problems, they only
apply as long as you've modeled your problem accurately enough.  And in
practice, people also settle for worse.  For instance, there's one
particular IDE that takes up twice as much disk space if you want to
use it for two programming languages.  By valuing freedom over anything
else, we already have to deal with false expectations when it comes to
hardware choices.  This is by far not the first time that we're hurt by
the consequences of short-sighted to harmful design decisions taking by
companies that only care about large numbers.

> I can't say that Haskell falls under the category of "modern," but it
> has been progressively "modernizing," adapting to the implications,
> whether good or bad. Javascript is definitely not new, and TypeScript
> is another example that is not new either.
Modernity itself is somewhat antiquated, and you can see the same issue
with programming languages.  We had a talk on postmodern C++ in 2017,
so languages that date back to the early 2010s qualify as "modern" in
my eye.  This also includes Javascript, which although a little older
than the rest, through npm pioneered the idea of horking up Python's
packaging model even harder.

> > > The current programming languages are made up of three [or four]
> > > parts:
> > > 
> > > 1. The languages itself
> > > 2. Language-server
> > > 3. The language packages
> > > 4. Language tools (formatter, linter)
> > > 
> > > It is possible to development without a language server, but many
> > > projects now require special formatting or running linter tools,
> > > etc. These are things that are somewhat basic in a certain way.
> > But as with all necessities, just because they're "basic" doesn't
> > mean that they're also available to the masses.  There are several
> > programming languages, where even getting to a compiler is
> > impossible, let alone the other three items on your list.  See [1]
> > on why that's a bad idea.
> > 
> 
> Does Guix have a plan to address this in the future or a workaround?
> I believe that in the future, this issue will become even more
> common, just as more languages have their own package managers, which
> are partly responsible for this huge dependency tree.
Let's stash away the thoughts about potential workarounds for now and
come back to them later.  The plan to address this in the future *is*
[1], that is bootstrapping all the tools we don't have (to the best of
our ability).

> > > In terms of programming languages, I have found almost all the
> > > ones I needed, with the exception of Kotlin.
> > [2]
> > 
> Thank, good to known that, just curious why/how nix have it.
My guess would be that they don't even bother building packages from
source in some cases.

> > > Regarding language servers, most of the ones I needed either
> > > haven't worked for me or don't exist. For example, Rust, Haskell,
> > > and Elm have few tools available
> > I wonder what all of those have in common.  🤔️
> > 
> > > [E]ven though I mainly program in Rust and Haskell, and lately,
> > > I've been getting into Guile, I also have old projects in Kotlin,
> > > for instance, or sometimes I like try other languages when `guix
> > > shell` is awesome.
> > > 
> > > So, sometimes I wish to do...
> > > 
> > > ```
> > > guix shell ghc haskell-language-server hlint
> > > ```
> > > 
> > > In that case, the language server isn't available. Another
> > > example:
> > I mean, you could try packaging it, assuming it has a reasonable
> > dependency graph.  Okay, you can stop laughing now.
> > 
> 
> You are absolutely right. As I mentioned before, the ever-increasing
> huge dependency tree is becoming more common in various programming
> languages due to the convenience of package managers. It is essential
> to have a plan on how to address these situations to ensure the
> long-term sustainability and maintainability of projects. Without a
> plan, it might be better not to embark on such a journey, as managing
> complex dependency chains can lead to numerous challenges and issues
> in the future. Projects like Guix need to actively consider
> strategies to handle and mitigate these complexities effectively to
> ensure a smooth and sustainable development process.
In order to effectively create a sustainable development process, we
need to break up with the current tradition of cramming the entire
internet into a binary and linking that statically, so everyone
afterwards has to do the same.

Of course, this is a hard solution to roll out, because it is a social
one rather than a technical one.  Sure, language package managers right
now enable you to put almost everything into your code and "have it
work".  That doesn't mean it's a good idea.  In fact, it's a pretty bad
one, and one that's at heart of all our software supply chain issues. 

> > 
> > > I appreciate the simplicity of Guix, but let's say that Nix has a
> > > developer-oriented approach and has become very popular among
> > > programmers. Many projects now include default configurations for
> > > Nix in their repositories.
> > Certainly, Nix enjoys clout, but there's nothing to stop you from
> > committing a guix.scm to your favourite project.  Case in point, I
> > recently contributed to one such project on Github (via mail to the
> > devs, of course).
> > 
> 
> Well, what holds me back is that many dependencies are missing, such
> as the basic ones I mentioned, making it impossible to use Guix in
> many cases. Others have non-ideal solutions, like one suggested in
> Matrix: `guix shell --container --emulate-fhs' + downloading the
> rustup script and installing it just to use clippy (the Rust linter).
> So, it's not feasible to include that in the project due to current
> limitations.
Why the hell is a linter included in your build process in the first
place?  I can understand that you might want to invoke one before
dropping the package maintainers a mail, I mean creating a pull
request, but it shouldn't matter otherwise.

By the way, remember when I earlier told you we'd come back to
workarounds later?  Now is later.  See, emulating the FHS means that
you fake being a regular old Linux distribution whose layout is as Rust
would expect without giving it write access to special folders of your
actual machine.  This is quite powerful indeed.

As for packaging clippy, you could try the crate importer, but there's
a chance that it does something useless, because Rust decided that
their own packaging strategy didn't work for it.  The same disclaimer
also holds for some GNOME projects that decided to use Rust because
it's the new hot stuff and decided not to follow its distribution
model.  This causes their packages to be form chimaeras of cargo and
meson and I don't know why they are actually content with that solution
beyond the observation that "it works".  

> > > Another issue is that if I wanted to bring Guix into the
> > > development workflow in a team, there would be the limitation of
> > > the OS.  While I promote free software in working groups, not
> > > everyone uses the same OS - some use GNU/Linux, some use Mac,
> > > etc. I think this is also part of the reason why Nix has
> > > succeeded in development environments.
> > If you have the metal to spare, why not help us ingest some Asahi
> > Linux patches?
> > 
> 
> Well, I think is not a real solution, a lot of time the people with
> those mac are from the companies and you are not able to change the
> OS, or sometimes you work as a freelancer in a company and other
> people use Mac and they don't want to change just becase an
> contractor have the idea of use Guix.
And that is fine.  Recall earlier when I mentioned "reasonable build
system based on GNU tools, CMake or Meson"?  Those tools work all the
same under other operating systems as well.  It's not like you have to
reinvent them for another programming language.  You can still use Guix
to improve your flow without forcing everyone to use it.  And there's
still a chance that at least part of the team will think that it's a
great idea, unless they have all sold Steve Jobs their souls.

> > > All this text is provided some context for two simple questions:
> > > 
> > > 1. Are there plans in the future to improve integration between
> > > development tools? For example, having haskell-language-server
> > > for ghc@9.x and another one for ghc@8.x, or something similar to
> > > the overwrite feature in Nix flake?
> > You mean other than --with-input?  Well, you can pray for the
> > upcoming USE flag light parameterized packages to become just that,
> > though I personally hope they don't, as there are more interesting
> > applications.
> > 
> 
> Maybe this will be the solution:
> https://blog.lispy.tech/parameterized-packages-the-second-update.html
The examples provided in that blog are already more interesting than
whatever you're trying to solve.

> > > 2. Do you see developers as a potential target audience for Guix,
> > > or is it mainly focused on HPC (High-Performance Computing)?
> > Well, the "developers" Guix sees as target audience typically refer
> > to themselves as hackers and don't think of themselves as an elite
> > that ought to be given exclusive access to their tools, but rather
> > as a vanguard party that wishes to make them available to all.
> > 
> > High performance computing is one application in which Guix makes a
> > lot of sense, but there are others ranging from academic over less
> > academic to everyday computing, games, and even running stress on
> > your CPU, GPU, and what other PUs you can nowadays put into
> > hardware to make number go up while the world is literally on fire.
> > 
> 
> Well, is someone want to hack with Rust/Haskell using Guix is not
> possible, They may end up taking alternative paths like in my case,
> or a mix of using Guix in some areas and not in others.
I don't think the reality is as bleak as you make it out to be.  Sure,
we probably don't carry cutting-edge versions of most Rust/Haskell
stuff out there, but depending on where you sit in the dependency tree,
you'll have an easier or harder time.  It's quite comfortably around
the trunk and rather shaky in the leaves, but it should at least be
manageable as long as it's a tree.  You'd just have to start actually
managing it.

Cheers
> > 

Re: Guix and the developer ecosystem

[(]

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> As for packaging clippy, you could try the crate importer, but there's
> a chance that it does something useless, because Rust decided that
> their own packaging strategy didn't work for it.  The same disclaimer
> also holds for some GNOME projects that decided to use Rust because
> it's the new hot stuff and decided not to follow its distribution
> model.  This causes their packages to be form chimaeras of cargo and
> meson and I don't know why they are actually content with that solution
> beyond the observation that "it works".  

Fairly sure clippy is included as part of cargo.

  -- (

Re: Guix and the developer ecosystem

[Liliana Marie Prikler]

Am Samstag, dem 05.08.2023 um 20:48 +0100 schrieb (:
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> > As for packaging clippy, you could try the crate importer, but
> > there's a chance that it does something useless, because Rust
> > decided that their own packaging strategy didn't work for it.  The
> > same disclaimer also holds for some GNOME projects that decided to
> > use Rust because it's the new hot stuff and decided not to follow
> > its distribution model.  This causes their packages to be form
> > chimaeras of cargo and meson and I don't know why they are actually
> > content with that solution beyond the observation that "it works". 
> 
> Fairly sure clippy is included as part of cargo.
Not sure whether it's a part of cargo, but at the very least it belongs
to the rust core.  Which again means nothing, because we have a rustfmt
output and a cargo output, but no clippy output.

Cheers

Re: Guix and the developer ecosystem

[Saku Laesvuori]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

>> Certainly, Nix enjoys clout, but there's nothing to stop you from
>> committing a guix.scm to your favourite project.  Case in point, I
>> recently contributed to one such project on Github (via mail to the
>> devs, of course).
>
>Well, what holds me back is that many dependencies are missing, such as
>the basic ones I mentioned, making it impossible to use Guix in many
>cases. [...] So, it's not
>feasible to include that in the project due to current limitations.

You could add the missing dependencies to the guix.scm. I often have ten
or so dependencies in my haskell projects' guix.scm files. It takes a
bit of time because the recursive hackage importer is currently broken
(https://issues.guix.gnu.org/64734), but it's not too bad because guix
already has most of the common packages.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Guix and the developer ecosystem

[(]

Hi,

Distopico <distopico@riseup.net> writes:
> In terms of programming languages, I have found almost all the ones I
> needed, with the exception of Kotlin.

The build sequence for Kotlin is some sort of hellish double
nightmare-loop of doooooooooooooom.  As far as I'm aware, this is how
the main dependencies of Kotlin relate to each other:

                     .---------------------.
                     |                     |
   .-------------> gradle ------.          V
   |                 ^          |        kotlin ------.
openjdk              '----------'        ^    ^       |
   |                                     |    '-------'
   '-------------------------------------'

Fun!

> In some languages like Haskell and GoLang, the language server depends a
> lot on the version it was compiled with. For example, I tried gopls,
> which is available in Guix, but it was built with Go 17 and is not
> compatible it.

Ah, that'll be because Guix uses Go 17 for building Go programs, unless
you override the ``#:go'' keyword, but the latest version of Go it
provides is Go 20.  I suppose it couldn't hurt to change it to be built
with the latest version.  (We can't just make the default build Go be
20, as that would require the CI to rebuild all Go packages.)

> All this text is provided some context for two simple questions:
>
> 1. Are there plans in the future to improve integration between
> development tools? For example, having haskell-language-server for
> ghc@9.x and another one for ghc@8.x, or something similar to the
> overwrite feature in Nix flake?
>
> is it mainly focused on HPC (High-Performance Computing)?

Definitely not :)

> I have started contributing to packages that I believe could be useful,
> and I like to contributing to teams such as Haskell or Rust. However,
> there are other topics, such as compiler and tools compatibility, where
> I'm not entirely clear about the direction that has been planned.

The problem with Haskell, Rust, and Elm is mainly, as lilyp has
said/implied, that while the dependency trees of C applications and such
typically resemble the following:

        O <-- O
  O <-- O <-- O
        O <-- O

dependency trees for Rust, Haskell, and Elm look like this:

                        / O
                  / O <-- O
                  |     \ O
                  |
                  |     / O
            / O <-- O <-- O
            |     |     \ O
            |     |
            |     |     / O
            |     \ O <-- O
            |           \ O
            |
            |           / O
            |     / O <-- O
            |     |     \ O
            |     |
            |     |     / O
  O <-- O <-- O <-- O <-- O
            |     |     \ O
            |     |
            |     |     / O
            |     \ O <-- O
            |           \ O
            |
            |           / O
            |     / O <-- O
            |     |     \ O
            |     |
            |     |     / O
            \ O <-- O <-- O
                  |     \ O
                  |
                  |     / O
                  \ O <-- O
                        \ O

Except in reality it's much much much much much worse.

So it's not because that's not something we'd like to have, it's largely
because packaging such things is a royal pain and there aren't all that
many people with the motivation to do that.

> And apologies for the lengthy text.

It's okay, questions are good :)

  -- (

Re: Guix and the developer ecosystem

[Distopico]

[-- Attachment #1: Type: text/plain, Size: 4215 bytes --]


On 2023-07-31, "(" <paren@disroot.org> wrote:

> Hi,
>
> Distopico <distopico@riseup.net> writes:
>> In terms of programming languages, I have found almost all the ones I
>> needed, with the exception of Kotlin.
>
> The build sequence for Kotlin is some sort of hellish double
> nightmare-loop of doooooooooooooom.  As far as I'm aware, this is how
> the main dependencies of Kotlin relate to each other:
>
>                      .---------------------.
>                      |                     |
>    .-------------> gradle ------.          V
>    |                 ^          |        kotlin ------.
> openjdk              '----------'        ^    ^       |
>    |                                     |    '-------'
>    '-------------------------------------'
>
> Fun!
>

Nice graphs, sound pretty complicate to solve that  :/

>> In some languages like Haskell and GoLang, the language server depends a
>> lot on the version it was compiled with. For example, I tried gopls,
>> which is available in Guix, but it was built with Go 17 and is not
>> compatible it.
>
> Ah, that'll be because Guix uses Go 17 for building Go programs, unless
> you override the ``#:go'' keyword, but the latest version of Go it
> provides is Go 20.  I suppose it couldn't hurt to change it to be built
> with the latest version.  (We can't just make the default build Go be
> 20, as that would require the CI to rebuild all Go packages.)
>

And that can be another problem, or it is indeed a real problem, going
to a project that uses Go 1.7, but all the tools are built around Go
1.20. That's why I imagine something like having tools relative to their
versions, so we can install gopls@0.11 and go@1.17 together because they
are compatible. And if I switch to another project, I could install
Go@1.15 and gopls@0.9.5. Currently, that is not possible, at least I
haven't seen it in Go/Rust/Haskell in Guix.

>> I have started contributing to packages that I believe could be useful,
>> and I like to contributing to teams such as Haskell or Rust. However,
>> there are other topics, such as compiler and tools compatibility, where
>> I'm not entirely clear about the direction that has been planned.
>
> The problem with Haskell, Rust, and Elm is mainly, as lilyp has
> said/implied, that while the dependency trees of C applications and such
> typically resemble the following:
>
>         O <-- O
>   O <-- O <-- O
>         O <-- O
>
> dependency trees for Rust, Haskell, and Elm look like this:
>
>                         / O
>                   / O <-- O
>                   |     \ O
>                   |
>                   |     / O
>             / O <-- O <-- O
>             |     |     \ O
>             |     |
>             |     |     / O
>             |     \ O <-- O
>             |           \ O
>             |
>             |           / O
>             |     / O <-- O
>             |     |     \ O
>             |     |
>             |     |     / O
>   O <-- O <-- O <-- O <-- O
>             |     |     \ O
>             |     |
>             |     |     / O
>             |     \ O <-- O
>             |           \ O
>             |
>             |           / O
>             |     / O <-- O
>             |     |     \ O
>             |     |
>             |     |     / O
>             \ O <-- O <-- O
>                   |     \ O
>                   |
>                   |     / O
>                   \ O <-- O
>                         \ O
>
> Except in reality it's much much much much much worse.
>
> So it's not because that's not something we'd like to have, it's largely
> because packaging such things is a royal pain and there aren't all that
> many people with the motivation to do that.
>


And this is the current reality, and it will become more and more
common, whether for better or for worse. Package managers make it so
convenient to install dependencies, but it leads to an abuse in that
regard. I could name many of the most widely used programming languages
today that have the same problem: JavaScript, Python, Haskell, Rust,
just to name a few. So, here is my question: Is there a future vision
for this situation? Because it will become more and more common over
time.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]

Re: Guix and the developer ecosystem

[Julien Lepiller]

Le 5 août 2023 03:49:30 GMT+02:00, Distopico <distopico@riseup.net> a écrit :
>
>On 2023-07-31, "(" <paren@disroot.org> wrote:
>
>> Hi,
>>
>> Distopico <distopico@riseup.net> writes:
>>> In terms of programming languages, I have found almost all the ones I
>>> needed, with the exception of Kotlin.
>>
>> The build sequence for Kotlin is some sort of hellish double
>> nightmare-loop of doooooooooooooom.  As far as I'm aware, this is how
>> the main dependencies of Kotlin relate to each other:
>>
>>                      .---------------------.
>>                      |                     |
>>    .-------------> gradle ------.          V
>>    |                 ^          |        kotlin ------.
>> openjdk              '----------'        ^    ^       |
>>    |                                     |    '-------'
>>    '-------------------------------------'
>>
>> Fun!
>>
>
>Nice graphs, sound pretty complicate to solve that  :/

There's hope, because you can skip building gradle, and manually build kotlin. So you end up with a chain of kotlin versions. I actually managed to build some, but I'm stuck after 1.0.0:

https://framagit.org/tyreunom/guix-android/-/blob/master/android/packages/kotlin.scm

That's already a huge chain, and it's probably missing ten times more…

>
>>> In some languages like Haskell and GoLang, the language server depends a
>>> lot on the version it was compiled with. For example, I tried gopls,
>>> which is available in Guix, but it was built with Go 17 and is not
>>> compatible it.
>>
>> Ah, that'll be because Guix uses Go 17 for building Go programs, unless
>> you override the ``#:go'' keyword, but the latest version of Go it
>> provides is Go 20.  I suppose it couldn't hurt to change it to be built
>> with the latest version.  (We can't just make the default build Go be
>> 20, as that would require the CI to rebuild all Go packages.)
>>
>
>And that can be another problem, or it is indeed a real problem, going
>to a project that uses Go 1.7, but all the tools are built around Go
>1.20. That's why I imagine something like having tools relative to their
>versions, so we can install gopls@0.11 and go@1.17 together because they
>are compatible. And if I switch to another project, I could install
>Go@1.15 and gopls@0.9.5. Currently, that is not possible, at least I
>haven't seen it in Go/Rust/Haskell in Guix.

There's always the time-machine or inferiors. If it worked at some point in Guix, you can go back in time and get those packages. Not ideal since they'll depend on older software, but at least, if it worked in the past, it's guaranteed to continue to work today.

>
>>> I have started contributing to packages that I believe could be useful,
>>> and I like to contributing to teams such as Haskell or Rust. However,
>>> there are other topics, such as compiler and tools compatibility, where
>>> I'm not entirely clear about the direction that has been planned.
>>
>> The problem with Haskell, Rust, and Elm is mainly, as lilyp has
>> said/implied, that while the dependency trees of C applications and such
>> typically resemble the following:
>>
>>         O <-- O
>>   O <-- O <-- O
>>         O <-- O
>>
>> dependency trees for Rust, Haskell, and Elm look like this:
>>
>>                         / O
>>                   / O <-- O
>>                   |     \ O
>>                   |
>>                   |     / O
>>             / O <-- O <-- O
>>             |     |     \ O
>>             |     |
>>             |     |     / O
>>             |     \ O <-- O
>>             |           \ O
>>             |
>>             |           / O
>>             |     / O <-- O
>>             |     |     \ O
>>             |     |
>>             |     |     / O
>>   O <-- O <-- O <-- O <-- O
>>             |     |     \ O
>>             |     |
>>             |     |     / O
>>             |     \ O <-- O
>>             |           \ O
>>             |
>>             |           / O
>>             |     / O <-- O
>>             |     |     \ O
>>             |     |
>>             |     |     / O
>>             \ O <-- O <-- O
>>                   |     \ O
>>                   |
>>                   |     / O
>>                   \ O <-- O
>>                         \ O
>>
>> Except in reality it's much much much much much worse.
>>
>> So it's not because that's not something we'd like to have, it's largely
>> because packaging such things is a royal pain and there aren't all that
>> many people with the motivation to do that.
>>
>
>
>And this is the current reality, and it will become more and more
>common, whether for better or for worse. Package managers make it so
>convenient to install dependencies, but it leads to an abuse in that
>regard. I could name many of the most widely used programming languages
>today that have the same problem: JavaScript, Python, Haskell, Rust,
>just to name a few. So, here is my question: Is there a future vision
>for this situation? Because it will become more and more common over
>time.

The solution to this issue could be better importers. The package managers of these languages manage to build the packages, so there's no reason we shouldn't be able to do so too. There are a few good importers, but others need to be written or polished to make them more reliable and useful.

Another approach could be to integrate guix in these tools. Maybe it would be good advertisement and incentivize developpers to make their package work well in guix. Imagine "pip export --guix some packages > guix.scm" or similar :)

On a more sociological point of view, we should raise these concerns to package managers and developpers to try and find a more satisfying solution.

Re: Guix and the developer ecosystem

[Wilko Meyer]

Hi,

Distopico <distopico@riseup.net> writes:

> 2. Do you see developers as a potential target audience for Guix, or is
> it mainly focused on HPC (High-Performance Computing)?

Developers is a pretty broad and generic term to start with. Considering
Guix is somewhat of a general purpose package manager/Guix System a
general purpose distribution, I think the better question to ask,
instead of asking for target audiences, is, how and in what way Guix
features and concepts can aid and help with hacking on software. HPC is
an area where Guix can be put to good use, but it's also a reasoanble
choice for other areas as well I'd argue.

IMHO Guix has plenty of useful features that, in my opinion, can be put
to good use in the process of developing software. I *mostly* work with
C and Rust, as well as Perl, and less frequently, Python and CommonLisp;
so my experience with Guix is mostly limited to these languages.

Using a guix.scm file for projects to provide a good way to spin up a
development environment fast/to onboard new people, and make use of guix
shell (mostly with --container) while working on software; are probably
my most used features in that regards.

Best Regards,

Wilko Meyer

Re: Guix and the developer ecosystem

[Distopico]

[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]


On 2023-07-31, Wilko Meyer <w@wmeyer.eu> wrote:

> Hi,
>
> Distopico <distopico@riseup.net> writes:
>
>> 2. Do you see developers as a potential target audience for Guix, or is
>> it mainly focused on HPC (High-Performance Computing)?
>
> Developers is a pretty broad and generic term to start with. Considering
> Guix is somewhat of a general purpose package manager/Guix System a
> general purpose distribution, I think the better question to ask,
> instead of asking for target audiences, is, how and in what way Guix
> features and concepts can aid and help with hacking on software. HPC is
> an area where Guix can be put to good use, but it's also a reasoanble
> choice for other areas as well I'd argue.
>
I believe one area for improvement is the possibility of having tools
and the compiler sharing common ground. For example, rust-1.6 with
rust-analyzer-1.6 with version 20220809 and rust-1.7 with
rust-analyzer-1.7 with version 20230911. In that case, similar to
rustup, we could do guix shell rust@1.6.8 rust-analyzer@20230911. In
Haskell, a similar issue occurs, where haskell-language-server, e.g.,
version 1.3, only works with specific GHC versions.

> IMHO Guix has plenty of useful features that, in my opinion, can be put
> to good use in the process of developing software. I *mostly* work with
> C and Rust, as well as Perl, and less frequently, Python and CommonLisp;
> so my experience with Guix is mostly limited to these languages.
>
How is your workflow with rust? I mean you use --container to just
download `rustup` and install it in the container?

> Using a guix.scm file for projects to provide a good way to spin up a
> development environment fast/to onboard new people, and make use of guix
> shell (mostly with --container) while working on software; are probably
> my most used features in that regards.
>

I do that as well, but in mostly of the cases just for me because other
team member can use it due is Gnu/Linux only, could be good have
something like emacs cross-platform.

> Best Regards,
>

Thank you for the reponse.

> Wilko Meyer


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]

Re: Guix and the developer ecosystem

[Ludovic Courtès]

Hi,

A late reply…

Distopico <distopico@riseup.net> skribis:

> 1. Are there plans in the future to improve integration between
> development tools? For example, having haskell-language-server for
> ghc@9.x and another one for ghc@8.x, or something similar to the
> overwrite feature in Nix flake?

I don’t think the project makes “plans” for such things.  To me, it
looks like mostly a matter of packaging; if ‘haskell-language-server’ is
missing, then some Haskeller may eventually feel the need to package it.
You can hope it’ll be someone else, but perhaps you’ll find that doing
it yourself is worth trying.  :-)

Regarding customization, ‘--with-input’ and perhaps other transformation
options may correspond to your needs:

  https://guix.gnu.org/manual/devel/en/html_node/Package-Transformation-Options.html

> 2. Do you see developers as a potential target audience for Guix, or is
> it mainly focused on HPC (High-Performance Computing)?

My dayjob has to do with HPC and I think Guix is a good fit for them.

But developers, whether in HPC or not, are definitely a target audience
IMO.  I believe Guix has great tools for development; that’s the spirit
of this blog post:

  https://guix.gnu.org/en/blog/2023/from-development-environments-to-continuous-integrationthe-ultimate-guide-to-software-development-with-guix/

Thanks for your feedback!

Ludo’.

Re: Guix and the developer ecosystem

[Distopico]

On 2023-08-16, Ludovic Courtès <ludo@gnu.org> wrote:

> Hi,
>
> A late reply…
>
> Distopico <distopico@riseup.net> skribis:
>
>> 1. Are there plans in the future to improve integration between
>> development tools? For example, having haskell-language-server for
>> ghc@9.x and another one for ghc@8.x, or something similar to the
>> overwrite feature in Nix flake?
>
> I don’t think the project makes “plans” for such things.  To me, it
> looks like mostly a matter of packaging; if ‘haskell-language-server’ is
> missing, then some Haskeller may eventually feel the need to package it.
> You can hope it’ll be someone else, but perhaps you’ll find that doing
> it yourself is worth trying.  :-)
>
> Regarding customization, ‘--with-input’ and perhaps other transformation
> options may correspond to your needs:
>
>   https://guix.gnu.org/manual/devel/en/html_node/Package-Transformation-Options.html
>

According with the docs, it will make rebuilt the packages so with
Rust/haskell that could take time and cpu, and for sure is a good option
in many cases, and maybe with Parameterized Packages[1] would be another
option, but what about have let said two packages like
`haskell-language-server-8.x` and `haskell-language-server-9.x` wherein
each one utilizes a predefined GHC version and prebuilt derivations? Is
this approach valid?


>> 2. Do you see developers as a potential target audience for Guix, or is
>> it mainly focused on HPC (High-Performance Computing)?
>
> My dayjob has to do with HPC and I think Guix is a good fit for them.
>
> But developers, whether in HPC or not, are definitely a target audience
> IMO.  I believe Guix has great tools for development; that’s the spirit
> of this blog post:
>
>   https://guix.gnu.org/en/blog/2023/from-development-environments-to-continuous-integrationthe-ultimate-guide-to-software-development-with-guix/
>
> Thanks for your feedback!
>
> Ludo’.

thank you for your response.

[1]: https://blog.lispy.tech/parameterized-packages-the-second-update.html

Re: Guix and the developer ecosystem

[Ludovic Courtès]

Hi,

Distopico <distopico@riseup.net> skribis:

>> Regarding customization, ‘--with-input’ and perhaps other transformation
>> options may correspond to your needs:
>>
>>   https://guix.gnu.org/manual/devel/en/html_node/Package-Transformation-Options.html
>>
>
> According with the docs, it will make rebuilt the packages so with
> Rust/haskell that could take time and cpu, and for sure is a good option
> in many cases, and maybe with Parameterized Packages[1] would be another
> option, but what about have let said two packages like
> `haskell-language-server-8.x` and `haskell-language-server-9.x` wherein
> each one utilizes a predefined GHC version and prebuilt derivations? Is
> this approach valid?

Yes, having one language server package for GHC 8 and another one for
GHC 9 sounds like the way to go: it gives flexibility for Haskell
developers and comes almost for free on the Guix side.

Thanks,
Ludo’.

Re: Guix and the developer ecosystem

[Distopico]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]


Nice, thanks for your response.

On 2023-08-24, Ludovic Courtès <ludo@gnu.org> wrote:

> Hi,
>
> Distopico <distopico@riseup.net> skribis:
>
>>> Regarding customization, ‘--with-input’ and perhaps other transformation
>>> options may correspond to your needs:
>>>
>>>   https://guix.gnu.org/manual/devel/en/html_node/Package-Transformation-Options.html
>>>
>>
>> According with the docs, it will make rebuilt the packages so with
>> Rust/haskell that could take time and cpu, and for sure is a good option
>> in many cases, and maybe with Parameterized Packages[1] would be another
>> option, but what about have let said two packages like
>> `haskell-language-server-8.x` and `haskell-language-server-9.x` wherein
>> each one utilizes a predefined GHC version and prebuilt derivations? Is
>> this approach valid?
>
> Yes, having one language server package for GHC 8 and another one for
> GHC 9 sounds like the way to go: it gives flexibility for Haskell
> developers and comes almost for free on the Guix side.
>
> Thanks,
> Ludo’.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]

Re: Guix and the developer ecosystem

[Simon Tournier]

Hi,

Thanks for your feedback.

On Wed, 26 Jul 2023 at 19:29, Distopico <distopico@riseup.net> wrote:

> So, in many cases, I haven't been able to fully integrate Guix into my
> development workflow. I had to look for alternative ways outside Guix,
> like Nix.
>
> I appreciate the simplicity of Guix, but let's say that Nix has a
> developer-oriented approach and has become very popular among
> programmers. Many projects now include default configurations for Nix in
> their repositories.

Hum, it seems an another issue about bootstrapping. ;-)

Well, on one hand, Guix is missing some person-power.  And on the other
hand, this allows to easily contribute, somehow.

Considering Haskell, the upstream community is putting their hands on
Nix.  For instance, people involved in GHC release management provide
some Nix stuff [1].  Well, if you follow the Haskell community, maybe
you know that some companies [2,3] are providing resources for making a
smooth and friendly Haskell development experience relying on Nix.

Similarly, if you are in academia, the experience using Guix for your
computations should be friendlier.  For example, working with R using
Guix is just smooth.  Or how easy is to apply package transformations in
order to benchmark some HPC stuff.  That’s because some research
institutes [4] are providing resources for making a smooth and friendly
experience.

Do not take me wrong, Guix is not focused on academia issues and Nix on
development ones.  Both are free software and the limitation is people
motivation, somehow.  Personally, I mainly use Guix for doing
computations in scientific context so most of my motivation is to
improve this area.  Improvements and the way to cover your needs is by
discussing your troubles and then by trying to fix them, i.e., by
sharing your hacks – even tiny ones.  Maybe another fellow hacker will
find that cool and they will be motivated for collaborating.  Thanks to
this collective sharing, we end up with tools that cover our needs, more
or less. :-)


1: https://gitlab.haskell.org/bgamari/ghcs-nix
2: https://well-typed.com/
3: https://www.tweag.io/
4: https://hpc.guix.info/


> Another issue is that if I wanted to bring Guix into the development
> workflow in a team, there would be the limitation of the OS. While I
> promote free software in working groups, not everyone uses the same OS -
> some use GNU/Linux, some use Mac, etc. I think this is also part of the
> reason why Nix has succeeded in development environments.

Somehow, I agree that having Guix running on other OSes than GNU/Linux
will be helpful in attracting users.  The archive provides such
attempts, for instance:

        Guix on macOS
        from Chris Marusich <cmmarusich@gmail.com>
        Wed, 11 Oct 2017 20:29:57 -0700
        https://yhetil.org/guix/87bmldavre.fsf@gmail.com

First, please note that it’s far to be trivial to port Guix on any other
OSes than GNU/Linux.  Then, from my understanding, the blocking point
is: you need to cheat using a very large binary seed or workarounds are
somehow required and need to be applied against the core C library.
Therefore, the intersection between all these deep technical
difficulties and skilled people able to deal with them is currently
empty.  Mainly because Guix is rooted with GNU principles and motivation
is not fungible.

That’s said, I know people that are running Guix on MacOS using Rosetta
and friends.  Well, that’s not the right place to discuss that because
we have to stay focus on free software. :-)


> 1. 
>                                      or something similar to the
> overwrite feature in Nix flake?

Could you explain what Nix flake is using Guix terms?


Cheers,
simon