3 ms·

Dependency management for Guile will be best handled via Guix - which handles not only Guile specific dependencies, but can replace the system package manager e

by sparkie 13y ago

Dependency management for Guile will be best handled via Guix - which handles not only Guile specific dependencies, but can replace the system package manager entirely, and perhaps parts of the crufty gnu build system too, now that you can define custom build processes in guix packages, and you can also use guile from GNU Make. Guix will also be used for configuration management too (since configurations are treated like packages.) Guix is really the killer app that will push Guile forwards, and towards realizing Guile for it was originally meant to be - an extension language for the GNU system. DMD is also being developed in Guile as part of the GNU system - to allow for dependency based daemon initialization without completely invading your system like certain others. I don't see Guile as a candidate for merely "tacking onto" existing apps like you typically do with Lua, but as more of an integrated part of a dynamically configurable operating system, much like emacs but for the whole system.

616c 13y ago
I have heard of Guix, and I am quite excited about it. I am just waiting for it to catch up for me. In this regard, Nix and NixOS are also fascinating. Maybe I am the last of the Linux kids using Stow, and I like it because it makes me worry less about source installations on my computer. It would be great to see Guix build on this idea. As much as I would love to transition to a new Linux distro, I would love even more having a ~/guix or ~/.guix path with different builds. If I really mess up my computer, I can delete this folder and all those binaries and the appropriate symlinks go away. This is what worries me about NixOS. Eventually with Stow NixOS, and other declarative package management you hit a little where you cannot outhink your dependenices. If your root is nixos and everything else is symlinked, that sounds hard for a mere mortal like me to debug. http://nixos.org/nixos/screenshots/nixos-terminals.png http://nixos.org/nixos/screenshots/nixos-terminals.png
- sparkie 13y ago
  You can already do that with guix and nix - they can run atop your distro and simply create new application directories where you want them. The actual builds are in /nix/store (or /guix/store), and symlinked from whatever profile you want (you can have several). It's also gonna be pretty hard to screw up your computer too, since multiple versions of software can be installed without problems, and you can perform safe rollbacks. The store is read-only and shouldn't be hard deleted by mortals anyway, but you should perform all the deletions through nix/guix. The advantage of building an OS out of nix/guix is that you generally don't want to perform any kind of change to a system which is not reproducible (ie, no "hidden knowledge" that went into configuring a system) - so that if your system does ever break due to some unforeseen circumstances, you have a declarative configuration of the system in its entirety before it broke, and you can rebuild the system in a few commands. It's probably worth abandoning the idea that applications (or symlinks) should go into /usr/bin or anywhere else - the need for symlinks exists mostly for compatibility, but from the POV of a package or configuration, you should only refer to a specific identity of a derivation in the store. For example, if I wanted a shortcut of say, emacs on my desktop - I could have a "desktop_icons.scm" package in which I define them - and rather than pointing to some /usr/bin/emacs, I would point to some "emacs" variable (referring to a specific version) imported from the emacs package, and append the relative bin path. Then if I change the version "emacs" points to, the desktop icon will be updated too.
  - davexunit 13y ago
    Nitpick: Guix uses /gnu/store now. :)

by sparkie 13y ago

616c 13y ago

I have heard of Guix, and I am quite excited about it. I am just waiting for it to catch up for me. In this regard, Nix and NixOS are also fascinating. Maybe I am the last of the Linux kids using Stow, and I like it because it makes me worry less about source installations on my computer. It would be great to see Guix build on this idea. As much as I would love to transition to a new Linux distro, I would love even more having a ~/guix or ~/.guix path with different builds. If I really mess up my computer, I can delete this folder and all those binaries and the appropriate symlinks go away. This is what worries me about NixOS. Eventually with Stow NixOS, and other declarative package management you hit a little where you cannot outhink your dependenices. If your root is nixos and everything else is symlinked, that sounds hard for a mere mortal like me to debug. http://nixos.org/nixos/screenshots/nixos-terminals.png http://nixos.org/nixos/screenshots/nixos-terminals.png

sparkie 13y ago
You can already do that with guix and nix - they can run atop your distro and simply create new application directories where you want them. The actual builds are in /nix/store (or /guix/store), and symlinked from whatever profile you want (you can have several). It's also gonna be pretty hard to screw up your computer too, since multiple versions of software can be installed without problems, and you can perform safe rollbacks. The store is read-only and shouldn't be hard deleted by mortals anyway, but you should perform all the deletions through nix/guix. The advantage of building an OS out of nix/guix is that you generally don't want to perform any kind of change to a system which is not reproducible (ie, no "hidden knowledge" that went into configuring a system) - so that if your system does ever break due to some unforeseen circumstances, you have a declarative configuration of the system in its entirety before it broke, and you can rebuild the system in a few commands. It's probably worth abandoning the idea that applications (or symlinks) should go into /usr/bin or anywhere else - the need for symlinks exists mostly for compatibility, but from the POV of a package or configuration, you should only refer to a specific identity of a derivation in the store. For example, if I wanted a shortcut of say, emacs on my desktop - I could have a "desktop_icons.scm" package in which I define them - and rather than pointing to some /usr/bin/emacs, I would point to some "emacs" variable (referring to a specific version) imported from the emacs package, and append the relative bin path. Then if I change the version "emacs" points to, the desktop icon will be updated too.
- davexunit 13y ago
  Nitpick: Guix uses /gnu/store now. :)