<ArneBab_>solrize: guix uses guile scheme, because one of its goals is to create a package manager for the GNU system which can leverage the power of guile scheme. As I understand it, that Guile is the canonical extension mechanism for GNU, that’s quite reasonable. See http://www.gnu.org/software/guix/
<ArneBab_>solrize: but civodul (as the main dev) can give you a better answer.
<ArneBab_>civodul: the qemu image worked out-of-the-box — nice!
<ArneBab_>(same for me - but testing whether guix is already suitable to install a local overlay is roughly part of my PhD task: make my work easier to reproduce for others. At least that’s my interpretation, and I have the freedom to schedule my time myself to some degree…
<sbp>this box is slow. instead of a CPU it has a cutout giraffe from the back of a cereal box
<sbp>civodul: there's a lot of "nix" hangover. are you going to s/nix/guix/g it all out by the time it gets to 1.0? or are you sticking with some nix parts for backwards compatibility with e.g. file paths?
***chaoflow_ is now known as chaoflow
<sbp>"Still here? Then perhaps by now you’ve started to wonder: when do we reach a fixed point? That is an interesting question! The answer is unknown, but if you would like to investigate further (and have significant computational and storage resources to do so), then let us know." — hehe
<sbp>the problem is that pip and gem and so on are still going to work as non-functional systems. I wonder if it would be possible to extend them individually so that they had hooks to interface the guix-daemon? then pip et al. would be compatible with guix, and the Functional Way™
<sbp>(then you have virtualenv which will probably be a whole new kettle of fish)
<sbp>also, if you're using /gnu, you should also reserve a gnu command. so then you could type `gnu install python` instead of `guix package -i python`. yes? yes? no? fine...
<klrr_>doesnt make sense honestly, naming the directory might be ok (i dont really have a opinion regarding that)
<klrr_>but guix is the package manager it would just be confusing to change its name from guix to gnu imo
<sbp>yeah, it was tongue in cheek. I mean, the fact that /gnu is being discussed for storage shows the primacy of the idea, the weight it holds within the GNU ecosystem. so `gnu` as a command was a reference to that too
<sbp>ideally, `guix install python` would be acceptable
<sbp>the overall joke was originally going to be that if you want to inform users of the pure-functional approach of guix on the command line, you could embed a pure-functional language in the command syntax
<sbp>or, better yet, guix functional-package-installation -i a -i b -i c
<sbp>guix functional-package-installation --fully-atomic-have-no-fear -i a -i b -i c
<sbp>I expect, thinking about it, that combinations of -i are going to be far more common than -i admixtured with non-i commands. so -i a b c, as you say, at the least would be handy. still think install is a good alias
<mark_weaver>sbp: well, if it helps, the 'guix' command is easily extensible, and you could add your desired 'install' command by simply adding a (guix scripts install) module somewhere in your guile load path.
<sbp>sure, and I'll put it up on github and it'll be the #1 downloaded repo and what's next? a ticker tape parade for sbp, that's what