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

31–40 of 51 posts

Re: Ruby on Guix

#31

Post by davexunit »

burke wrote: post #30
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.

For the record, I do not tolerate "download and run this random package installer!" either, without GPG signed binaries and corresponding source.

Re: Ruby on Guix

#32

Post by waxjar »

I like the approach of using gs (simple gemsets) [1] and dep (simple dependencies) [2]. I've been using this approach of handling dependencies for a while now.

I've written a simple shell script as a replacement for gs (since I constantly forget if I was in a sub-shell or not). All it does is change $GEM_PATH and $GEM_HOME when $PWD changes (while staying in the same shell). If the current $PWD has a directory ".gs", `gem install` will install them there instead of globally. All I have to remember is to create a .gs directory when I start a new project.

It does not address all issues highlighted in the article, nor do I know how well this would work in a production environment with automated deployments. It's probably more of a work around than a solution. I vastly prefer it for personal projects, though. Hate solving gem conflicts with "bundle exec".

[1]: https://github.com/soveran/gs [2]: https://github.com/cyx/dep

Re: Ruby on Guix

#33

Post by miah_ »

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.

no 'ruby version manager', eg 'chruby, rvm, or rbenv' make any sense in the nix/guix world. the article would have done a disservice to itself to go into detail on each one, when the goal was really to show how to manage ruby projects in guix.

Re: Ruby on Guix

#35

Post by buren »

davexunit wrote: post #18
buren wrote: post #2

Looks pretty cool, though it is a pretty daunting task to convince all gem developers to test/make their gems compatible. Perhaps this could make http://devblog.avdi.org/2015/08/11/what-its-like-to-come-bac... easier ;)

I don't expect to convince all gem developers by any means, but it doesn't hurt to ask nicely if the brave few would give it a try. ;)

I certainly will :)

Re: Ruby on Guix

#36

Post by heroic »

davexunit wrote: post #31
burke wrote: post #30

Earlier quoted context omitted.

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.

For the record, I do not tolerate "download and run this random package installer!" either, without GPG signed binaries and corresponding source.

I am quite sure RVM now offers a signed download too.

https://rvm.io/rvm/security

Re: Ruby on Guix

#37

Post by regularfry »

waxjar wrote: post #32

I like the approach of using gs (simple gemsets) [1] and dep (simple dependencies) [2]. I've been using this approach of handling dependencies for a while now. I've written a simple shell script as a replacement for gs (since I constantly forget if I was in a sub-shell or not). All it does is change $GEM_PATH and $GEM_HOME when $PWD changes (while staying in the same shell). If the current $PWD has a directory ".gs",…

Instead of changing environment variables when $PWD changes, I went the other way: make it obvious when you're in a subshell by strapping $VIRTUAL_ENV onto $PS1. Again, simple shell scripts win[0][1].

I'm still interested in a cross-language approach, but I'm suspicious of anything which requires an explicit import step for rubygems that doesn't involve resolving the dependency tree. Unless Gemfile.lock is involved, it's going to need to copy Bundler's resolution algorithm, which seems fraught.

[0]: https://github.com/regularfry/gemsh [1]: https://github.com/regularfry/rv

Re: Ruby on Guix

#38

Post by regularfry »

ownedthx wrote: post #9

As someone who deploys Ruby software to our servers, I've come up with a formula that's served us well. We take all gems associated with the app (like a Rails app, but we do it with others), and stuff them along with the code into a package created by fpm. In other words, the packages are completely self-contained; no gems are used from the environment. The key to this is the --path option to bundle install, i.e.: bu…

Yep, this works well. Not sure if fpm handles native package dependencies too, but that's a very-nice-to-have.

Re: Ruby on Guix

#39

Post by davexunit »

regularfry wrote: post #37
waxjar wrote: post #32

I like the approach of using gs (simple gemsets) [1] and dep (simple dependencies) [2]. I've been using this approach of handling dependencies for a while now. I've written a simple shell script as a replacement for gs (since I constantly forget if I was in a sub-shell or not). All it does is change $GEM_PATH and $GEM_HOME when $PWD changes (while staying in the same shell). If the current $PWD has a directory ".gs",…

Instead of changing environment variables when $PWD changes, I went the other way: make it obvious when you're in a subshell by strapping $VIRTUAL_ENV onto $PS1. Again, simple shell scripts win[0][1]. I'm still interested in a cross-language approach, but I'm suspicious of anything which requires an explicit import step for rubygems that doesn't involve resolving the dependency tree. Unless Gemfile.lock is involved,…

>but I'm suspicious of anything which requires an explicit import step for rubygems that doesn't involve resolving the dependency tree.

The current 'guix import gem' utility doesn't do dependency resolution at all. It just generates some Scheme code for you to start with and you fill in the gaps. It's important to understand that Guix packages specify the exact versions of its dependencies. That includes not only the version number, but its explicit dependencies, the Ruby used during the build, the GCC used for native extensions, the full build script, etc. All of these various inputs to the build function are reflected in the SHA256 hash that uniquely identifies that package.

The loose versioning that Bundler uses is indeed very flawed and prone to strange errors. Guix simply doesn't have this issue.

Re: Ruby on Guix

#40

Post by sanderjd »

schneems wrote: post #34

I really hope no one is ever doing `rails >= 4.0` in their Gemfile.

Yeah, while I think the approach outlined in the post makes sense and could be really great, I really haven't had any of the problems outlined since the bad old `config.gem` days. In my experience, everyone defaults `~> X.Y.Z` dependencies, with more lenient patterns justified by actual testing, and I can't remember the last time I saw a blanket `>= X` requirement. This has meant that all, or very nearly so, of the dependency problems I find myself handling are due to actual incompatibility, which I'm glad were caught.
Post reply on HN