Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby on Guix

dthompson.us

Post reply on HN
Print view View original

21–30 of 51 posts

Re: Ruby on Guix

#21

Post by rekado »

1_player wrote: post #20
davexunit wrote: post #17

Earlier quoted context omitted.

Yes, the 'guix environment' tool is like a language-agnostic virtualenv. Guix does not use or interfere with any components from the host distro, so you can install Guix on top of Arch Linux without fear. We have a binary installation method[0] that isn't too difficult that you can try out. I use Guix on top of an Ubuntu host at work. For your PostgreSQL example, you'd still need to do things like initialize the DB c…

The point was to install the deps into my project tree, instead of putting everything into /gnu, but to think of it that's not actually much of a problem, it's just personal preference/bikeshedding. I'm installing it and see how it goes, thanks.

"Installing" a package with Guix really just means that it is referenced through a link. /gnu is just a cache for "evaluated" package recipes. You could create a profile that contains your symlinks to the items in the store wherever you want, including the currenty directory.

    guix package -p $(pwd)/.guix-profile -i what ever you want
Programmes in this profile can then be executed like so:

    ./.guix-profile/bin/what
But that's not necessary when you could just use `guix environment` and enter a shell where everything is already hooked up.

Re: Ruby on Guix

#22

Post by 3pt14159 »

What is exactly wrong with piping curl into bash? I'm trusting RVM anyway. As for functional package managers, I'll believe it when I see it. The reason things are brittle is that any time something in the middle of a dependency chain changes the whole chain may break. The more you freeze things, the greater chance there is to freeze up a security hole (see what is going on with Docker). So you have two choices: be ok with the freeze, or update the whole chain. In this respect I prefer the latter, and I especially prefer the way Ruby does it where, due to the global namespace, I'm forced to upgrade the gem everywhere so I end up fixing things and keeping the whole project up to date. While this seems frustrating at first, once you realize that everyone in the Ruby community is doing it, you realize that the reason it is usually painless to update your gems is because other people have fixed those other holes. What is especially nice is that you only have to remember things that are broken at T0, unlike, say, Node, where a popular nested node_module may have 10 different versions in your dependencies and you keep hitting the same bug or security hole over and over again.

Re: Ruby on Guix

#27

Post by davexunit »

lighthawk wrote: post #26

Nothing about rbenv in the post. Any reason why not? Some of the things you pointed out about rvm would be handled by using rbenv instead.

I should have made a note that I've been using rbenv as an escape from rvm and it has roughly the same set of problems, but it is a bit less enraging.

Re: Ruby on Guix

#28

Post by pdkl95 »

davexunit wrote: post #27
lighthawk wrote: post #26

Nothing about rbenv in the post. Any reason why not? Some of the things you pointed out about rvm would be handled by using rbenv instead.

I should have made a note that I've been using rbenv as an escape from rvm and it has roughly the same set of problems, but it is a bit less enraging.

As someone who tried RVM for a while and until it's problems became obvious, and lived (very successfully) with rbenv as an escape for a long time afterwords, I have been liking chruby:

https://github.com/postmodern/chruby

It doesn't have most of the problems of RVM/rbenv, and mainly provides an easy way to switch between rubies while leaving everything else as full-path references instead of the "magic" tht RVM tries to provide.

That said, I really like the local $GEM_HOME method, and guix sounds like an interesting solution.

Re: Ruby on Guix

#29

Post by davexunit »

pdkl95 wrote: post #28
davexunit wrote: post #27

Earlier quoted context omitted.

I should have made a note that I've been using rbenv as an escape from rvm and it has roughly the same set of problems, but it is a bit less enraging.

As someone who tried RVM for a while and until it's problems became obvious, and lived (very successfully) with rbenv as an escape for a long time afterwords, I have been liking chruby: https://github.com/postmodern/chruby It doesn't have most of the problems of RVM/rbenv, and mainly provides an easy way to switch between rubies while leaving everything else as full-path references instead of the "magic" tht RVM trie…

Thank you. I think the benefits of Guix start to become even more evident when you work in a multi-language environment with god knows how many package managers. We don't yet have all the packages that people need, but that will happen in time if other people see value in Guix. We will see.

Re: Ruby on Guix

#30

Post by burke »

3pt14159 wrote: post #22

What is exactly wrong with piping curl into bash? I'm trusting RVM anyway . As for functional package managers, I'll believe it when I see it. The reason things are brittle is that any time something in the middle of a dependency chain changes the whole chain may break. The more you freeze things, the greater chance there is to freeze up a security hole (see what is going on with Docker). So you have two choices: be…

I've found all the hate surrounding this practice to be pretty misdirected. As long as it's served over https, it's functionally equivalent to "download and run this random package installer!", which is generally tolerated.
Post reply on HN