Re: Guix and the developer ecosystem
Nice, thanks for your response. On 2023-08-24, Ludovic Courtès wrote: > Hi, > > Distopico 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’. signature.asc Description: PGP signature
Re: Guix and the developer ecosystem
Hi, Distopico 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
Hi, Thanks for your feedback. On Wed, 26 Jul 2023 at 19:29, Distopico 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 Wed, 11 Oct 2017 20:29:57 -0700 https://yhetil.org/guix/87bmldavre@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
Re: Guix and the developer ecosystem
On 2023-08-16, Ludovic Courtès wrote: > Hi, > > A late reply… > > Distopico 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
Hi, A late reply… Distopico 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
>> 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. signature.asc Description: PGP signature
Re: Guix and the developer ecosystem
Am Samstag, dem 05.08.2023 um 20:48 +0100 schrieb (: > Liliana Marie Prikler 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
Liliana Marie Prikler 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
Hi Distopico, Am Freitag, dem 04.08.2023 um 20:11 -0500 schrieb Distopico: > > On 2023-07-29, Liliana Marie Prikler > 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 > > > ``` > > > > >
Re: Guix and the developer ecosystem
Le 5 août 2023 03:49:30 GMT+02:00, Distopico a écrit :
>
>On 2023-07-31, "(" wrote:
>
>> Hi,
>>
>> Distopico 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 doom. 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
Re: Guix and the developer ecosystem
On 2023-07-31, "(" wrote:
> Hi,
>
> Distopico 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 doom. 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.
signature.asc
Description: PGP signature
Re: Guix and the developer ecosystem
On 2023-07-31, Wilko Meyer wrote: > Hi, > > Distopico 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 signature.asc Description: PGP signature
Re: Guix and the developer ecosystem
On 2023-07-29, Liliana Marie Prikler 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,
Re: Guix and the developer ecosystem
Hi, Distopico 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
Hi, Distopico 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 doom. 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
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
Guix and the developer ecosystem
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.
