11 ms·

Guix for Development

133 points by phlummox 4y ago

amelius 4y ago
Kind of disappointing that the Guix pytorch package has no GPU support: https://guix.gnu.org/en/packages/python-pytorch-1.12.0/ https://guix.gnu.org/en/packages/python-pytorch-1.12.0/ This makes me wonder if Guix is ready for the real world.
- grnmamba 4y ago
  Can't say the N word in Guix I think Guix is more than ready for providing development environments, even for proprietary apps on open source technology stacks (but Nix will probably be easier to pitch). As an operating system much less so.
  - amelius 4y ago
    > Can't say the N word in Guix nVidia? Nix? Or Nonguix?
    - maartenh 4y ago
      Yes. Don't forget about non-GNU.
      - 0x457 4y ago
        Also, Nonfree.
    - grnmamba 4y ago
      In the context of pytorch: nvidia
- zetalyrae 4y ago
  If Guix uses Nix under the hood, is it "just" Nix with an S-expression syntax (admittedly much better than Nix syntax) and fewer packages? If so, is there a really compelling reason to prefer Guix over NixOS? The only substantive difference I'm aware of is the use of GNU Shepherd instead of systemd.
  - fiddlerwoaroof 4y ago
    As far as I know it doesn't use nix under the hood, it's a reimplementation of nix in guile scheme.
    - zetalyrae 4y ago
      Ah, my mistake. I was certain it wrapped around Nix for some reason.
      - cygx 4y ago
        Same backend, but different frontend, so to speak. Hence, it used to be possible to have nix and guix share a store and local state directory. Not sure if that's still possible today, though...
        filterfish 4y ago
        It isn't.
- yjftsjthsd-h 4y ago
  > This makes me wonder if Guix is ready for the real world. ML and GPUs are a smallish subset of the real world, and a subset that's particularly plagued by proprietary software (especially the GPU side); I don't think it's a good litmus test for "is guix useful for real work".
  - amelius 4y ago
    ML and GPUs are on HN's front page almost every day ...
    - nextos 4y ago
      You can use this channel to get non-GNU sanctioned software, including kernels and drivers: https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix Furthermore, you can install Nix in Guix: https://guix.gnu.org/packages/nix-2.5.1 https://guix.gnu.org/packages/nix-2.5.1
      - behnamoh 4y ago
        then why not just install Nix in the first place??
        nextos 4y ago
        I use NixOS, but GuixSD users might find this option useful.
        ParetoOptimal 4y ago
        You prefer using guix but want a package Nix has already packaged and don't have the time and knowledge to package it yourself.
    - dan-robertson 4y ago
      There are a bunch of things that come up regularly on HN that aren’t particularly relevant to the real world so I don’t think this logic is good. Though I think you are correct that ML is relevant to the real world. However when you wrote ‘the real world’ you didn’t mean the thing for which ML is relevant but rather ‘being a general purpose operating system that is useful [to software developers]’ and for this I think the lack of hardware-accelerated PyTorch isn’t great but I don’t think training/running ML models is particularly relevant to being a general purpose OS (even for software developers). I’m not sure it’s even relevant to ML practitioners as I would expect they’d be farming out training to a dedicated compute cluster. One needs to jump through a bunch of hoops to get hardware-accelerated PyTorch on Apple’s latest computers. Does that mean they aren’t ready for the real world?
- dannymi 4y ago
  I tried to change Guix to enable vulkan in pytorch and I get a build error. Since I don't use pytorch I didn't investigate further. If you do know the build options to make this work, Guix will gladly consider your patch. The in-progress diff would be, diff --git a/gnu/packages/machine-learning.scm b/gnu/packages/machine-learning.scm index e702e499fc..73af29487d 100644 --- a/gnu/packages/machine-learning.scm +++ b/gnu/packages/machine-learning.scm @@ -101,6 +101,7 @@ (define-module (gnu packages machine-learning) #:use-module (gnu packages swig) #:use-module (gnu packages tls) #:use-module (gnu packages video) + #:use-module (gnu packages vulkan) #:use-module (gnu packages web) #:use-module (gnu packages xml) #:use-module (gnu packages xorg) @@ -2897,6 +2898,10 @@ (define-public python-pytorch (build-system python-build-system) (arguments '(#:phases (modify-phases %standard-phases + (add-before 'build 'use-vulkan + (lambda _ + (setenv "USE_VULKAN" "1") + (setenv "USE_VULKAN_SHADERC_RUNTIME" "1"))) (add-before 'build 'use-system-libraries (lambda\* (#:key outputs #:allow-other-keys) ;; Tell 'setup.py' to let 'CMakeLists.txt' know that we @@ -2973,7 +2978,11 @@ (define-public python-pytorch pthreadpool protobuf pybind11 + shaderc sleef + glslang spirv-headers ;spirv-tools ; not sure why this is needed + vulkan-headers + vulkan-loader xnnpack zstd)) (propagated-inputs Error messages: FAILED: bin/scalar_test : && /gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/bin/c++ -Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp -DNDEBUG -DUSE_KINETO -DLIBKINETO_NOCUPTI -DUSE_QNNPACK -DUSE_PYTORCH_QN NPACK -DUSE_XNNPACK -DUSE_VULKAN -DUSE_VULKAN_API -DUSE_VULKAN_SHADERC_RUNTIME -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -DEDGE_PROFILER_USE_KINETO -O2 -fPIC -Wno-narrowing -Wall -Wextra -Werror=return-type -Wno-missing -field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-unused-parameter -Wno-unused-function -Wno-unused-result -Wno-unused-local-typedefs -Wno-strict-overflow -Wno-strict-aliasing -Wno -error=deprecated-declarations -Wno-stringop-overflow -Wno-psabi -Wno-error=pedantic -Wno-error=redundant-decls -Wno-error=old-style-cast -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wn o-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Werror=cast-function-type -Wno-stringop-overflow -DHAVE_AVX512_CPU_DEFINITION -DHAVE_AVX2_CPU_DEFINITION -O3 -DNDEBUG -DNDEBUG -rdynamic - pthread caffe2/CMakeFiles/scalar_test.dir/__/aten/src/ATen/test/scalar_test.cpp.o -o bin/scalar_test -Wl,-rpath,/tmp/guix-build-python-pytorch-1.12.0.drv-0/source/build/lib: -lgtest_main -lgtest /gnu/store/0 94bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libgomp.so /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so -Wl,--no-as-needed,"/tmp/guix-build-python-pytorch-1.12.0.drv-0/source/bui ld/lib/libtorch.so" -Wl,--as-needed -Wl,--no-as-needed,"/tmp/guix-build-python-pytorch-1.12.0.drv-0/source/build/lib/libtorch_cpu.so" -Wl,--as-needed /gnu/store/9pyydl5w9xnz1qm56sxn1zh4qny6fkxz-protobuf-3.17.3 /lib/libprotobuf.so lib/libc10.so -pthread && : ld: /tmp/guix-build-python-pytorch-1.12.0.drv-0/source/build/lib/libtorch_cpu.so: undefined reference to `glslang::TShader::setNanMinMaxClamp(bool)' ld: /tmp/guix-build-python-pytorch-1.12.0.drv-0/source/build/lib/libtorch_cpu.so: undefined reference to `spvtools::CreateCompactIdsPass()' [...] The reason is because pytorch 1.12.0 depends on shaderc-2020.4/lib/libshaderc_combined.a--and static libraries do not have automatic dependency resolution, so spirv, glsl etc is never linked.
- pxc 4y ago
  Guix already sees use in the 'real world' in a number of HPC environments.
ed25519FUUU 4y ago
Probably because I’m not a lisp person but the syntax is just ugly and not intuitive. It would look much better as a yaml file and I don’t even really like yaml either.
- eointierney 4y ago
  Learn Sanskrit not BNF Tongue in cheek :)
- 0x457 4y ago
  I don't like lisp syntax, but honestly, I would rather use this language than whatever nix is. It can't be a yaml file because it's essentially a program, it's a lot easier to write such things as a program.
  - colordrops 4y ago
    If you know Lisp or Haskell then Emacs and XMonad are great. If you don't, then you just get lost trying to configure them. Nix lang is a much simpler DSL with affordances like nice list syntax. It may be less powerful than lisp but it's easy to edit and (relatively) quick to learn. Similar to vimscript, which sucks, but it's amenable to easy edits for the unwashed masses.
    - deleted 4y ago
      [deleted]
    - 0x457 4y ago
      My issue with Nix-lang is that it's somewhere between declarative and uhm…not declarative? Certain sections of nix files have special meaning (config), certain functions only work in those sections. Nice features like `//` for merging dicts goes out of the window as soon as you have nested dict, which is nearly every time. It's poorly documented, “standard library” documentation is even worse. It's impossible to navigate because everything is mashed together in `nixpkgs`. Often show no examples on how to use a function and just say `it takes blahblah`, but what is blahblah?
dan-robertson 4y ago
The idea that you can easily type a command and be quickly dumped into a development environment for some software your system runs is amazing. I think it’s something that actually brings people closer towards some of the ideals of GNU or Open Source and better lets you take advantage of everything being open source. (Aside: I think this is also great about Emacs; you can easily jump to the source of most things and there’s usually a way to hack or modify or inspect or debug them immediately). One thing I couldn’t work out how to do in guix was to go the whole way through. Something like: 1. Install / use some program 2. Find some bug or potential improvement 3. Run the command to be dumped into a dev environment for that 4. Fix or investigate the bug; or implement the improvement 5. (The step I don’t know how to do) Use your fixed/improved version in your operating system 6. (Also don’t know how to leverage guix for this) Share your improvements with others It feels like 5 is somewhat at odds with how guix is meant to work as step 4 is so mutation-heavy, but it also feels like something that an OS which wants to be as gnu as possible should really want to support. And gui should be able to make it safer too by giving you rollbacks. Maybe there’s an easy way to do it and I just don’t know it?
- dannymi 4y ago
  For step 5: guix install foo --with-source=foo=yourfixedversion_src.tar.gz Or: guix install foo --with-patch=foo=yourpatch.patch (note: usually packages are installed as regular user into your user profile) See also section "Package Transformation Options" in "info guix". For step 6, send a mail with the patch to the package definition (in an existing scm file in https://git.savannah.gnu.org/git/guix.git https://git.savannah.gnu.org/git/guix.git ) to the guix-devel mailing list. But whatever you did manually to get yourfixedversion_src.tar.gz you now should automate by programming the patching process in Scheme instead--editing a guix checkout (usually just to add: (add-after 'unpack 'patch-problematic-stuff-4711 (lambda _ (substitute* "somefile" (("regex1") "replacement"))))). For more complicated fixes, add a patch to the guix checkout and make Guix use it in Scheme (and contribute it to the actual foo upstream project--which we usually do anyway). See section "Contributing" in "info guix". Further automation welcome-- and probably not that difficult to add. Just keep in mind that each package build is in its own container (it's kinda like Docker would be)--so no mixing text editor and building and weird user-defined pauses (for example there is no text editor in the build container).
pvinis 4y ago
It's basically the same as https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf than, plus lisp for config?
- rgoulter 4y ago
  Sortof. AFAIU, asdf is for providing particular versions of tools (e.g. python, etc.). In the original post, guix is also used to provide library dependencies. Guix is the free software oriented, lisp flavored cousin of Nix. -- I've used Nix. It's got enough rough edges that writing nix code is pretty much only accessible to enthusiasts.. though, those who can get past the rough edges do recommend it. The added complexity of guix/nix allow for having an OS distribution where the whole OS config is declared/reproducible.
fiddlerwoaroof 4y ago
I use nix but, as a user of Common Lisp, I’d much rather use guix: the main blocker for me is that nix supports macOS and guix refuses to for ideological reasons.
- rekado 4y ago
  No, Guix does not refuse to support macos and not for ideological reasons either. Where do you get your info? There is no way to build the package graph on macos. There is no glibc port for macos, and there's no free toolchain we could legally use. There is little value in building Guix when we are forced to use a different proprietary toolchain, a different C library, and throw away the from-source bootstrap in exchange for Gigabytes of proprietary blobs. You might as well use Guix System in a virtual machine on macos.
  - fiddlerwoaroof 4y ago
    The value of Guix on macOS is that your users can use the same project definitions on macOS and Linux. I don't personally care about the "from-source bootstrap" all that much, I want tooling that I can use to express my system's configuration as code and nix does this just fine on macOS. As far as the ideological reasons goes, last time I looked for this, someone on a mailing list asked how you'd go about porting guix to macOS and some core team member answered they had no interest in supporting a non-FOSS system.
    - rekado 4y ago
      Guix has recently landed support for building Guix System containers on top of WSL2. Emacs (another GNU package) also runs just fine on Windows. This is not about supporting a non-free system; I bet some nuance was left behind on the way from writing that mailing list post to the comment I'm responding to. Building packages for macOS would require an entirely different underpinning --- or cheating but cutting the package graph and grafting it on top of the huge proprietary blob that is the macOS development environment. It would also require that we buy macOS licenses and operate macOS build farm nodes to build binaries. And for what? The resulting packages would in no way be equivalent to their GNU+Linux counterparts. The "same project definitions" would not describe the same thing at all.
BaculumMeumEst 4y ago
The thing that really bums me out about Guix is that Emacs debugging tools for Guile aren't anywhere near as good as you get with Edebug for Emacs Lisp or similar functionality for Common Lisp, Racket, or Clojure. With any of those languages you set breakpoints, display results, evaluate expressions, etc all with a very nice interface. With guile, you get none of that, there's seemingly no debugging tooling at all. The best Emacs integration you get is Geiser which is not a GNU project and doesn't offer the debugging functionality mentioned above. This is very surprising considering that Emacs and Guix are under one roof, and Guix is arguably GNU's flagship new software. Why do the development tools suck?
- tmtvl 4y ago
  Guile is severely lacking in manpower, people on the mailing list have talked about possibly improving the situation; but it's difficult to get any major movement going.
  - BaculumMeumEst 4y ago
    I'm definitely not qualified to know how hard it would be to improve the tooling, I just know greg hendershott single handedly did racket's tooling for Emacs. I'm just surprised there's not more interest considering how cool it would be to be able to spelunk through Guix internals with good debugging tools.
throwway9028232 4y ago
Doesn't work on on macOS from what I last saw, so I use Nix.
guilhas 4y ago
I started to use it recently I it is easier than expected, and I never used lisp or similar before The documentation is good It still has problems here and there, and packages missing. Probably due to the lack of wide adoption for being new and different But packages that are missing, most are easy to create or find online, to use in your private repository, or submit to main repository There was less difficulties than expected. Things that didn't work, or I didn't wanted to waste time fixing
deleted 4y ago
[deleted]
kazinator 4y ago
I don't understand how the Guix documentation can refer to #:uninterned #:symbols as "keywords"; was that written with a straight face? Yikes. Common Lisp's single : sigil is perfect for keywords; two characters is excessive. Why does gnu-build-system use %standard-phases (a symbol with %)? You'd think it could just use standard-phases. What is the big namespace concern. The % prefix is a Lisp convention for implementation internal symbols, not to be used by user code. Kind of like double underscore in C. It could simply be the mplicit default. If most rules use %standard-phases, it's silly to be repeating it all over the place. modify-phases could have a syntax like: (modify-phases {phases-object | clause }*) If an argument is a phases-object, then it's taken as the current object on which the remaining clauses operate. Otherwise it's a clause like (add-after ...). The initial current object is understood to be %standard-phases. Now you just do: (modify-phases (add-after 'unpack 'bootstrap (lambda _ (invoke "sh" "bootstrap"))) One piece of noise gone; N more to go. About the lambda, a simple idea would be that if the registered function is a list object (pair), then it's treated as list of exec arguments: (modify-phases (add-after 'unpack 'bootstrap '("sh" "bootstrap"))) either add-after performs the transformation to lambda + invoke, or else the object stays as a list, and is later treated as a command to execute. A macro like (cmdf "sh bootstrap") could do the parsing and generate the lambda + invoke. The "f" reminds you that it doesn't run the command but returns a function.
- yyyk2 4y ago
  It's written in Guile, which is a variant of Scheme. #: is used as the keyword indicator, not an uninterned symbol like in CL. > Why does gnu-build-system use %standard-phases (a symbol with %) AFAIK %symbol indicates a constant in Scheme. It's unfortunate that it isn't written in Common Lisp. CLOS would've been immensely useful there instead of the ad-hoc object system via Scheme records.

133 points by phlummox 4y ago

Kind of disappointing that the Guix pytorch package has no GPU support: https://guix.gnu.org/en/packages/python-pytorch-1.12.0/ https://guix.gnu.org/en/packages/python-pytorch-1.12.0/ This makes me wonder if Guix is ready for the real world.

grnmamba 4y ago
Can't say the N word in Guix I think Guix is more than ready for providing development environments, even for proprietary apps on open source technology stacks (but Nix will probably be easier to pitch). As an operating system much less so.
- amelius 4y ago
  > Can't say the N word in Guix nVidia? Nix? Or Nonguix?
  - maartenh 4y ago
    Yes. Don't forget about non-GNU.
    - 0x457 4y ago
      Also, Nonfree.
  - grnmamba 4y ago
    In the context of pytorch: nvidia
zetalyrae 4y ago
If Guix uses Nix under the hood, is it "just" Nix with an S-expression syntax (admittedly much better than Nix syntax) and fewer packages? If so, is there a really compelling reason to prefer Guix over NixOS? The only substantive difference I'm aware of is the use of GNU Shepherd instead of systemd.
- fiddlerwoaroof 4y ago
  As far as I know it doesn't use nix under the hood, it's a reimplementation of nix in guile scheme.
  - zetalyrae 4y ago
    Ah, my mistake. I was certain it wrapped around Nix for some reason.
    - cygx 4y ago
      Same backend, but different frontend, so to speak. Hence, it used to be possible to have nix and guix share a store and local state directory. Not sure if that's still possible today, though...
      - filterfish 4y ago
        It isn't.
yjftsjthsd-h 4y ago
> This makes me wonder if Guix is ready for the real world. ML and GPUs are a smallish subset of the real world, and a subset that's particularly plagued by proprietary software (especially the GPU side); I don't think it's a good litmus test for "is guix useful for real work".
- amelius 4y ago
  ML and GPUs are on HN's front page almost every day ...
  - nextos 4y ago
    You can use this channel to get non-GNU sanctioned software, including kernels and drivers: https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix Furthermore, you can install Nix in Guix: https://guix.gnu.org/packages/nix-2.5.1 https://guix.gnu.org/packages/nix-2.5.1
    - behnamoh 4y ago
      then why not just install Nix in the first place??
      - nextos 4y ago
        I use NixOS, but GuixSD users might find this option useful.
      - ParetoOptimal 4y ago
        You prefer using guix but want a package Nix has already packaged and don't have the time and knowledge to package it yourself.
  - dan-robertson 4y ago
    There are a bunch of things that come up regularly on HN that aren’t particularly relevant to the real world so I don’t think this logic is good. Though I think you are correct that ML is relevant to the real world. However when you wrote ‘the real world’ you didn’t mean the thing for which ML is relevant but rather ‘being a general purpose operating system that is useful [to software developers]’ and for this I think the lack of hardware-accelerated PyTorch isn’t great but I don’t think training/running ML models is particularly relevant to being a general purpose OS (even for software developers). I’m not sure it’s even relevant to ML practitioners as I would expect they’d be farming out training to a dedicated compute cluster. One needs to jump through a bunch of hoops to get hardware-accelerated PyTorch on Apple’s latest computers. Does that mean they aren’t ready for the real world?
dannymi 4y ago
I tried to change Guix to enable vulkan in pytorch and I get a build error. Since I don't use pytorch I didn't investigate further. If you do know the build options to make this work, Guix will gladly consider your patch. The in-progress diff would be, diff --git a/gnu/packages/machine-learning.scm b/gnu/packages/machine-learning.scm index e702e499fc..73af29487d 100644 --- a/gnu/packages/machine-learning.scm +++ b/gnu/packages/machine-learning.scm @@ -101,6 +101,7 @@ (define-module (gnu packages machine-learning) #:use-module (gnu packages swig) #:use-module (gnu packages tls) #:use-module (gnu packages video) + #:use-module (gnu packages vulkan) #:use-module (gnu packages web) #:use-module (gnu packages xml) #:use-module (gnu packages xorg) @@ -2897,6 +2898,10 @@ (define-public python-pytorch (build-system python-build-system) (arguments '(#:phases (modify-phases %standard-phases + (add-before 'build 'use-vulkan + (lambda _ + (setenv "USE_VULKAN" "1") + (setenv "USE_VULKAN_SHADERC_RUNTIME" "1"))) (add-before 'build 'use-system-libraries (lambda\* (#:key outputs #:allow-other-keys) ;; Tell 'setup.py' to let 'CMakeLists.txt' know that we @@ -2973,7 +2978,11 @@ (define-public python-pytorch pthreadpool protobuf pybind11 + shaderc sleef + glslang spirv-headers ;spirv-tools ; not sure why this is needed + vulkan-headers + vulkan-loader xnnpack zstd)) (propagated-inputs Error messages: FAILED: bin/scalar_test : && /gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/bin/c++ -Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp -DNDEBUG -DUSE_KINETO -DLIBKINETO_NOCUPTI -DUSE_QNNPACK -DUSE_PYTORCH_QN NPACK -DUSE_XNNPACK -DUSE_VULKAN -DUSE_VULKAN_API -DUSE_VULKAN_SHADERC_RUNTIME -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -DEDGE_PROFILER_USE_KINETO -O2 -fPIC -Wno-narrowing -Wall -Wextra -Werror=return-type -Wno-missing -field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-unused-parameter -Wno-unused-function -Wno-unused-result -Wno-unused-local-typedefs -Wno-strict-overflow -Wno-strict-aliasing -Wno -error=deprecated-declarations -Wno-stringop-overflow -Wno-psabi -Wno-error=pedantic -Wno-error=redundant-decls -Wno-error=old-style-cast -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wn o-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Werror=cast-function-type -Wno-stringop-overflow -DHAVE_AVX512_CPU_DEFINITION -DHAVE_AVX2_CPU_DEFINITION -O3 -DNDEBUG -DNDEBUG -rdynamic - pthread caffe2/CMakeFiles/scalar_test.dir/__/aten/src/ATen/test/scalar_test.cpp.o -o bin/scalar_test -Wl,-rpath,/tmp/guix-build-python-pytorch-1.12.0.drv-0/source/build/lib: -lgtest_main -lgtest /gnu/store/0 94bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libgomp.so /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so -Wl,--no-as-needed,"/tmp/guix-build-python-pytorch-1.12.0.drv-0/source/bui ld/lib/libtorch.so" -Wl,--as-needed -Wl,--no-as-needed,"/tmp/guix-build-python-pytorch-1.12.0.drv-0/source/build/lib/libtorch_cpu.so" -Wl,--as-needed /gnu/store/9pyydl5w9xnz1qm56sxn1zh4qny6fkxz-protobuf-3.17.3 /lib/libprotobuf.so lib/libc10.so -pthread && : ld: /tmp/guix-build-python-pytorch-1.12.0.drv-0/source/build/lib/libtorch_cpu.so: undefined reference to `glslang::TShader::setNanMinMaxClamp(bool)' ld: /tmp/guix-build-python-pytorch-1.12.0.drv-0/source/build/lib/libtorch_cpu.so: undefined reference to `spvtools::CreateCompactIdsPass()' [...] The reason is because pytorch 1.12.0 depends on shaderc-2020.4/lib/libshaderc_combined.a--and static libraries do not have automatic dependency resolution, so spirv, glsl etc is never linked.
pxc 4y ago
Guix already sees use in the 'real world' in a number of HPC environments.

ed25519FUUU 4y ago

Probably because I’m not a lisp person but the syntax is just ugly and not intuitive. It would look much better as a yaml file and I don’t even really like yaml either.

eointierney 4y ago
Learn Sanskrit not BNF Tongue in cheek :)
0x457 4y ago
I don't like lisp syntax, but honestly, I would rather use this language than whatever nix is. It can't be a yaml file because it's essentially a program, it's a lot easier to write such things as a program.
- colordrops 4y ago
  If you know Lisp or Haskell then Emacs and XMonad are great. If you don't, then you just get lost trying to configure them. Nix lang is a much simpler DSL with affordances like nice list syntax. It may be less powerful than lisp but it's easy to edit and (relatively) quick to learn. Similar to vimscript, which sucks, but it's amenable to easy edits for the unwashed masses.
  - deleted 4y ago
    [deleted]
  - 0x457 4y ago
    My issue with Nix-lang is that it's somewhere between declarative and uhm…not declarative? Certain sections of nix files have special meaning (config), certain functions only work in those sections. Nice features like `//` for merging dicts goes out of the window as soon as you have nested dict, which is nearly every time. It's poorly documented, “standard library” documentation is even worse. It's impossible to navigate because everything is mashed together in `nixpkgs`. Often show no examples on how to use a function and just say `it takes blahblah`, but what is blahblah?

dan-robertson 4y ago

The idea that you can easily type a command and be quickly dumped into a development environment for some software your system runs is amazing. I think it’s something that actually brings people closer towards some of the ideals of GNU or Open Source and better lets you take advantage of everything being open source. (Aside: I think this is also great about Emacs; you can easily jump to the source of most things and there’s usually a way to hack or modify or inspect or debug them immediately). One thing I couldn’t work out how to do in guix was to go the whole way through. Something like: 1. Install / use some program 2. Find some bug or potential improvement 3. Run the command to be dumped into a dev environment for that 4. Fix or investigate the bug; or implement the improvement 5. (The step I don’t know how to do) Use your fixed/improved version in your operating system 6. (Also don’t know how to leverage guix for this) Share your improvements with others It feels like 5 is somewhat at odds with how guix is meant to work as step 4 is so mutation-heavy, but it also feels like something that an OS which wants to be as gnu as possible should really want to support. And gui should be able to make it safer too by giving you rollbacks. Maybe there’s an easy way to do it and I just don’t know it?

dannymi 4y ago
For step 5: guix install foo --with-source=foo=yourfixedversion_src.tar.gz Or: guix install foo --with-patch=foo=yourpatch.patch (note: usually packages are installed as regular user into your user profile) See also section "Package Transformation Options" in "info guix". For step 6, send a mail with the patch to the package definition (in an existing scm file in https://git.savannah.gnu.org/git/guix.git https://git.savannah.gnu.org/git/guix.git ) to the guix-devel mailing list. But whatever you did manually to get yourfixedversion_src.tar.gz you now should automate by programming the patching process in Scheme instead--editing a guix checkout (usually just to add: (add-after 'unpack 'patch-problematic-stuff-4711 (lambda _ (substitute* "somefile" (("regex1") "replacement"))))). For more complicated fixes, add a patch to the guix checkout and make Guix use it in Scheme (and contribute it to the actual foo upstream project--which we usually do anyway). See section "Contributing" in "info guix". Further automation welcome-- and probably not that difficult to add. Just keep in mind that each package build is in its own container (it's kinda like Docker would be)--so no mixing text editor and building and weird user-defined pauses (for example there is no text editor in the build container).

pvinis 4y ago

It's basically the same as https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf than, plus lisp for config?

rgoulter 4y ago
Sortof. AFAIU, asdf is for providing particular versions of tools (e.g. python, etc.). In the original post, guix is also used to provide library dependencies. Guix is the free software oriented, lisp flavored cousin of Nix. -- I've used Nix. It's got enough rough edges that writing nix code is pretty much only accessible to enthusiasts.. though, those who can get past the rough edges do recommend it. The added complexity of guix/nix allow for having an OS distribution where the whole OS config is declared/reproducible.

fiddlerwoaroof 4y ago

I use nix but, as a user of Common Lisp, I’d much rather use guix: the main blocker for me is that nix supports macOS and guix refuses to for ideological reasons.

rekado 4y ago
No, Guix does not refuse to support macos and not for ideological reasons either. Where do you get your info? There is no way to build the package graph on macos. There is no glibc port for macos, and there's no free toolchain we could legally use. There is little value in building Guix when we are forced to use a different proprietary toolchain, a different C library, and throw away the from-source bootstrap in exchange for Gigabytes of proprietary blobs. You might as well use Guix System in a virtual machine on macos.
- fiddlerwoaroof 4y ago
  The value of Guix on macOS is that your users can use the same project definitions on macOS and Linux. I don't personally care about the "from-source bootstrap" all that much, I want tooling that I can use to express my system's configuration as code and nix does this just fine on macOS. As far as the ideological reasons goes, last time I looked for this, someone on a mailing list asked how you'd go about porting guix to macOS and some core team member answered they had no interest in supporting a non-FOSS system.
  - rekado 4y ago
    Guix has recently landed support for building Guix System containers on top of WSL2. Emacs (another GNU package) also runs just fine on Windows. This is not about supporting a non-free system; I bet some nuance was left behind on the way from writing that mailing list post to the comment I'm responding to. Building packages for macOS would require an entirely different underpinning --- or cheating but cutting the package graph and grafting it on top of the huge proprietary blob that is the macOS development environment. It would also require that we buy macOS licenses and operate macOS build farm nodes to build binaries. And for what? The resulting packages would in no way be equivalent to their GNU+Linux counterparts. The "same project definitions" would not describe the same thing at all.

BaculumMeumEst 4y ago

The thing that really bums me out about Guix is that Emacs debugging tools for Guile aren't anywhere near as good as you get with Edebug for Emacs Lisp or similar functionality for Common Lisp, Racket, or Clojure. With any of those languages you set breakpoints, display results, evaluate expressions, etc all with a very nice interface. With guile, you get none of that, there's seemingly no debugging tooling at all. The best Emacs integration you get is Geiser which is not a GNU project and doesn't offer the debugging functionality mentioned above. This is very surprising considering that Emacs and Guix are under one roof, and Guix is arguably GNU's flagship new software. Why do the development tools suck?

tmtvl 4y ago
Guile is severely lacking in manpower, people on the mailing list have talked about possibly improving the situation; but it's difficult to get any major movement going.
- BaculumMeumEst 4y ago
  I'm definitely not qualified to know how hard it would be to improve the tooling, I just know greg hendershott single handedly did racket's tooling for Emacs. I'm just surprised there's not more interest considering how cool it would be to be able to spelunk through Guix internals with good debugging tools.

throwway9028232 4y ago

Doesn't work on on macOS from what I last saw, so I use Nix.

guilhas 4y ago

I started to use it recently I it is easier than expected, and I never used lisp or similar before The documentation is good It still has problems here and there, and packages missing. Probably due to the lack of wide adoption for being new and different But packages that are missing, most are easy to create or find online, to use in your private repository, or submit to main repository There was less difficulties than expected. Things that didn't work, or I didn't wanted to waste time fixing

deleted 4y ago

[deleted]

kazinator 4y ago

I don't understand how the Guix documentation can refer to #:uninterned #:symbols as "keywords"; was that written with a straight face? Yikes. Common Lisp's single : sigil is perfect for keywords; two characters is excessive. Why does gnu-build-system use %standard-phases (a symbol with %)? You'd think it could just use standard-phases. What is the big namespace concern. The % prefix is a Lisp convention for implementation internal symbols, not to be used by user code. Kind of like double underscore in C. It could simply be the mplicit default. If most rules use %standard-phases, it's silly to be repeating it all over the place. modify-phases could have a syntax like: (modify-phases {phases-object | clause }*) If an argument is a phases-object, then it's taken as the current object on which the remaining clauses operate. Otherwise it's a clause like (add-after ...). The initial current object is understood to be %standard-phases. Now you just do: (modify-phases (add-after 'unpack 'bootstrap (lambda _ (invoke "sh" "bootstrap"))) One piece of noise gone; N more to go. About the lambda, a simple idea would be that if the registered function is a list object (pair), then it's treated as list of exec arguments: (modify-phases (add-after 'unpack 'bootstrap '("sh" "bootstrap"))) either add-after performs the transformation to lambda + invoke, or else the object stays as a list, and is later treated as a command to execute. A macro like (cmdf "sh bootstrap") could do the parsing and generate the lambda + invoke. The "f" reminds you that it doesn't run the command but returns a function.

yyyk2 4y ago
It's written in Guile, which is a variant of Scheme. #: is used as the keyword indicator, not an uninterned symbol like in CL. > Why does gnu-build-system use %standard-phases (a symbol with %) AFAIK %symbol indicates a constant in Scheme. It's unfortunate that it isn't written in Common Lisp. CLOS would've been immensely useful there instead of the ad-hoc object system via Scheme records.