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).
To be perfectly honest, I don't make operating-system-specific packages (in Python, the language I use on a daily basis). I make standard Python distutils packages, and then anyone who has Python can install them anywhere. Folks who want to can generate RPM, extracting Windows .exe, etc., from that package.
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 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?
Over in the Python world, pip supports a scheme for specifying either the package name on the main Python package index, or a combo of repo URL + name to install under. Works with SVN, hg and git repositories, IIRC, and lets you pin to specific points in the repository, which ends up being pretty useful if you want to develop against a consistent snapshot of a dependency.
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!
This runs into issues when the code relies on anything outside of the lib/ directory. This is because Rip only copies the lib/ directory (and bin/). Bug reported http://github.com/defunkt/rip/issues#issue/25 and being worked on but I wanted to give the heads up.
This actually sounds very similar to the package manager we're working on for Narwhal (http://narwhaljs.org/), currently called "Tusk". It has virtualenv-style environments, dependency resolution, installation from git repos or plain HTTP servers.
Perhaps we could collaborate to make a language-agnostic package management "standard". We can of course have implementations in our languages of choice, but things like the .rip file format, directory structure, etc could be standardized.
That would be very interesting. I was thinking about this problem for a while, and would like to participate.
What I like in rubygems is that (1) it works on the 3 major OSes, (2) it compiles code for me, if the stars are aligned in the right way, and (3) there is an open central repository.
Achieving the first 2 out of 3 would rock. 3 could happen later.
23 comments
[ 336 ms ] story [ 1074 ms ] threadThat means every Ruby code written and hosted publicly can be installed locally by Rip?
Now we will need a special search engine just for Ruby :D
It's not the most simple problem and I was limited during development to my own setup and the setup of a few peers.
I'd love to get it rock solid and take it where it needs to go.
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 feel your pain. That's where it all began.
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?
`latest` or `rip-latest` or some such?
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!
Perhaps we could collaborate to make a language-agnostic package management "standard". We can of course have implementations in our languages of choice, but things like the .rip file format, directory structure, etc could be standardized.
What I like in rubygems is that (1) it works on the 3 major OSes, (2) it compiles code for me, if the stars are aligned in the right way, and (3) there is an open central repository.
Achieving the first 2 out of 3 would rock. 3 could happen later.