6 ms·
Is this like Ruby's Bundler for Python? I've just been getting into Python and am really glad to see this, thanks for creating it!
by choxi 10y ago
Is this like Ruby's Bundler for Python? I've just been getting into Python and am really glad to see this, thanks for creating it!
- uranusjr 10y agoWithout some shim like bundler exec, but yeah, you can say that.
- igravious 10y agoVery 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 10y agoActually we could also learn from: - the JS community. npm dependancy graph, webpack resolver and yarn performances; - the rust community like with cargo.
- K0nserv 10y agoBundler 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 https://github.com/CocoaPods/Molinillo 1: http://cocopods.org/ http://cocopods.org/
- sametmax 10y agoI 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 ?
- igravious 10y agoThis 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!
- mhw 10y ago> 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-build 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.)
- pkd 10y ago> 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 10y agoUsing RVM is not always an option and some might consider it an anti-pattern.
- igravious 10y agoGreat 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 .