Hi, Thanks for your feedback.
On Wed, 26 Jul 2023 at 19:29, Distopico <distop...@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 <cmmarus...@gmail.com> 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
