[igravious]

Very similar. I think Pipenv improves on Bundler by leveraging Virtualenv and Ruby doesn't have a per project equivalent to Virtualenv that I'm aware of. You can set the path config variable of Bundler to not place the project Gems in a central location which I think is cleaner and try to remember to always do now.

It would be _super_ interesting if the Python and Ruby communities got together to harmonize every last detail of their packaging toolchain. Who is in?

[sametmax]

Actually we could also learn from:

- the JS community. npm dependancy graph, webpack resolver and yarn performances;

- the rust community like with cargo.

[K0nserv]

Bundler does proper dependency resolution using Molinillo[0] which is also used by CocoaPods[1]. This is definitely something that other package managers can stand to adopt.

0: https://github.com/CocoaPods/Molinillo 1: http://cocopods.org/

[igravious]

This is exactly what I was trying to get at with my original comment. There needs to be a lot more sharing of package management tools and techniques across language boundaries. Generic platform- and language-agnostic tools and algorithms are a step in the right direction!

[sametmax]

I have a big doubt about Molinillo. The readme doesn't even link to a documentation.

Does it allow you to update one package or the executable version and get a list of all the stuff to update ?

[mhw]

> Ruby doesn't have a per project equivalent to Virtualenv that I'm aware of.

The nearest equivalent is to place a file called '.ruby-version' in the top level directory, containing the version number of the Ruby you want to use. Version numbers come from https://github.com/rbenv/ruby-build/tree/master/share/ruby-b.... rbenv, chruby and rvm all support .ruby-version.

One difference from virtualenv is that the Ruby version managers share single installations of each version of Ruby. My understanding from occasional use of Virtualenv is that it copies the python installation into a new per-project subdirectory, which seems a bit wasteful to me.

> You can set the path config variable of Bundler to not place the project Gems in a central location which I think is cleaner and try to remember to always do now.

Yes, this is what I do. It gives me a shared 'clean' Ruby installation of the right version, plus a project-specific copy of all the gems the project depends on. To me this provides the best trade off between project isolation and not duplicating the whole world. You can set bundler up so this is done automatically by creating '~/.bundle/config' containing

    ---
    BUNDLE_PATH: "vendor/bundle"
    BUNDLE_BIN: ".bundle/bin"

(The BUNDLE_PATH one is the important one; see 'bundle config --help' for other options.)

[igravious]

Great to here you also do what I do with the path config variable. I was just reading the documentation and Bundler has an opinion about deployment as well. I must look into that. I will also start making sure I am using/setting .ruby-version .

[pkd]

> It gives me a shared 'clean' Ruby installation of the right version, plus a project-specific copy of all the gems the project depends on

You can also accomplish the same using gemsets which are provided by rvm.

[igravious]

Using RVM is not always an option and some might consider it an anti-pattern.