Why yet another dependency management library?
The idea behind Dependencies is that RubyGems is only one way of getting a sane $LOAD_PATH. So this library is aimed to solve a few problems: • Documentation: the dependencies file specifies everything your project needs in order to run. This is great both for developers and sysadmins. • Vendoring: after trying the alternative, we found vendoring our dependencies is best as the application is self-contained. Again, this is good for developers because you update your dependencies together with your code, and it’s good for sysadmins as they don’t need to worry about installing new dependencies as the project evolves. So Dependencies makes it very easy to simply vendor everything while keeping a clean list of what’s needed. There are other alternatives to managing dependencies and we’re looking into ways of being compatible with them. At the moment we’re focusing on Rip and Heroku’s .gems manifest, but don’t hesitate to get in touch if you want to collaborate. If you’re interested in depe
Related Questions
- What does 1 copy available at Collection Management in ON-ORDER or 1 copy available at Central Library in ON-ORDER mean?
- I am concerned about dependency management. What is the thinking of supporting us and dependencies?
- What is the difference between the MA and the MSc in Information and Library Management?
