Live data from Hacker News

Rip: Ruby's Intelligent Packaging

hellorip.com

11–20 of 24 posts

Re: Rip: Ruby's Intelligent Packaging

#11
To me, easily the most compelling feature is multiple environment management.

I am constantly bitten by this, say, whenever I want to run multiple Ruby/Rails apps on the same machine.

Experiencing "can't activate foo (= 2.0, runtime), already activated foo-1.0" errors is a terrible way to start the work week.

I'd like to hear more about how it resolves dependency conflicts more conveniently than Rubygems though.

Re: Rip: Ruby's Intelligent Packaging

#12
post #10

How do people deploy with walled-garden package managers like this? Do you write an LSB RPM which depends on Ruby and stuff like your local syslog and net-snmp configs, and runs "gem install rip" and "rip install whatever" for you?

I avoid them entirely by copying the source of my Ruby dependencies into my source tree. That way I can deploy to a fresh machine with a simple checkout. This isn't foolproof (compiled/installed dependencies) but it helps.

I do this with Python also, but yeah, the compiled/installed dependencies can be problematic. Especially if you have multiple platforms to support (Windows, OSX, Linux).

Re: Rip: Ruby's Intelligent Packaging

#13
I like how the rip deps file is a list of canonical URLs and tag/version numbers!

Question: How would I use rip to track the latest version of each dependency -- maybe one is a gem and so I want the latest gem on rubyforge, but another is a github repo + branch, and another is an obscure fork on gitorious. Is there a way that Rip can tell if there are newer versions of the libs available?

Re: Rip: Ruby's Intelligent Packaging

#14
Heh, like pip, it relies on the previous package management tool (gems and easy_install) to install itself.

rip isn't just a mix of pip and virtualenv though, it's also got bits of functionality from virtualenvwrapper (manages multiple envs) and buildout (plugins) mixed in there.

There is no way to work with gems in a development format? e.g. straight from version control?

I like Buildout's approach of doing script generation better though, since it allows for multiple working sets of packages within the same environment. And you can manage stuff besides just language-specific packages, such as database installs, config files, etc, etc. Plus you can manage libraries from more than just one language - perfect for those franken-Python-Perl-Ruby projects.

Looks like a big improvement over the rails/gem_dependencies sillyness of embedding a package management tool into a web framework though!

Re: Rip: Ruby's Intelligent Packaging

#15
post #14

Heh, like pip, it relies on the previous package management tool (gems and easy_install) to install itself. rip isn't just a mix of pip and virtualenv though, it's also got bits of functionality from virtualenvwrapper (manages multiple envs) and buildout (plugins) mixed in there. There is no way to work with gems in a development format? e.g. straight from version control? I like Buildout's approach of doing script g…

That's true, I do use virtualenvwrapper and was inspired by it as well. I'm adding it to the README now.

Re: Rip: Ruby's Intelligent Packaging

#16
post #11

To me, easily the most compelling feature is multiple environment management. I am constantly bitten by this, say, whenever I want to run multiple Ruby/Rails apps on the same machine. Experiencing "can't activate foo (= 2.0, runtime), already activated foo-1.0" errors is a terrible way to start the work week. I'd like to hear more about how it resolves dependency conflicts more conveniently than Rubygems though.

I got back from Railsconf and couldn't start the GitHub Rails app because of some dependency issues caused by a random gem I had installed at the conference.

I feel your pain. That's where it all began.

Re: Rip: Ruby's Intelligent Packaging

#17

I like how the rip deps file is a list of canonical URLs and tag/version numbers! Question: How would I use rip to track the latest version of each dependency -- maybe one is a gem and so I want the latest gem on rubyforge, but another is a github repo + branch, and another is an obscure fork on gitorious. Is there a way that Rip can tell if there are newer versions of the libs available?

There's no support for this currently, but maybe we should introduce syntax in the .rip file?

`latest` or `rip-latest` or some such?

Re: Rip: Ruby's Intelligent Packaging

#19
post #14

Heh, like pip, it relies on the previous package management tool (gems and easy_install) to install itself. rip isn't just a mix of pip and virtualenv though, it's also got bits of functionality from virtualenvwrapper (manages multiple envs) and buildout (plugins) mixed in there. There is no way to work with gems in a development format? e.g. straight from version control? I like Buildout's approach of doing script g…

Actually, you can install it just from the tarball. It's pretty easy. (Check the Without RubyGems section of the install page.)

Re: Rip: Ruby's Intelligent Packaging

#20
post #17

I like how the rip deps file is a list of canonical URLs and tag/version numbers! Question: How would I use rip to track the latest version of each dependency -- maybe one is a gem and so I want the latest gem on rubyforge, but another is a github repo + branch, and another is an obscure fork on gitorious. Is there a way that Rip can tell if there are newer versions of the libs available?

There's no support for this currently, but maybe we should introduce syntax in the .rip file? `latest` or `rip-latest` or some such?

that sounds awesome
Post reply on HN