3 ms·
What's the best practice here, for avoiding deploy-time dependencies on RubyGems.org in general, and specific RubyGems.org-hosted gems in particular? I've been
by JohnBooty 6y ago
What's the best practice here, for avoiding deploy-time dependencies on RubyGems.org in general, and specific RubyGems.org-hosted gems in particular?
I've been doing Rails for a number of years on medium-sized teams. However, I have been lucky/unlucky enough to have generally been distanced from the devops side of things.
Bundler lets you vendor your gems directly, obviously, but that seems like a non-starter from a practical standpoint when we consider the size of Rails+dependencies.
- dsr_ 6y agoIf you work on a non-open-source project using libraries from open-source projects, you should always: 1. have the ability to rebuild everything from your own repo, without requiring an external source to be available. 2. Specify versions of every library, preferably with a hash of their contents in some form, that gets checked at build time. 3. Subscribe to the serious bugs, announce, security, and/or major release lists for each library, so that you know when something big is happening. 4. Keep old versions that you used. 5. Update to new versions only when you have an expressible need. Every bit of software has a cost. Sometimes that cost is in dollars, sometimes in reciprocity, and always in awareness.
- JohnBooty 6y agoRight - those are the goals and they are crucial ones. I was thinking "best practices" in terms of, well, practice. The implementation of things to achieve those goals. The most obvious thing one could do in Ruby land is to vendor one's gem dependencies with bundler, but I'm not sure how that works in conjunction with a typical git-based workflow.