4 ms·

This is why you vendor gems, and the current accepted practice of not vendoring gems is dead wrong. I've been chastised before in rails irc for this. I strongl

• delano 14y ago
  That's how Maven works but to a fault. The huge dependency repo tends to bog down deployments/releases. Today I use bundler but my solution back in the (java) day was to separate code releases from dependency releases (separate directories basically). e.g. /path/2/project /path/2/project-resources
• pmahoney 14y ago
  > source of all dependencies possible should be in your repository How far do you go? Do you include libxml for building nokogiri? Heck, do you include libc and gcc for building any gem with a C extension? Coming from Java, Maven and something like Nexus Sonatype make it easy (for certain values of "easy") to run a proxy repository. The equivalent of all "gem install <some_gem>" goes through the proxy, which continues to serve gems even if the original source goes away. I don't particularly like the inclusion of dependencies in a repository. Is this a custom version "some guy" long gone from the company created three years ago? Can I safely upgrade it to get security fix <X>? I suppose similar questions arise no matter the source... This is reason why you cryptographically sign your gems before publishing them. I (unfortunately) had not known this was supported by RubyGems, but it is: http://docs.rubygems.org/read/chapter/21 http://docs.rubygems.org/read/chapter/21 But I'll bet very few gems are signed. Rails does not appear to be: $ gem install rails -P HighSecurity ERROR: While executing gem ... (Gem::Exception) Unsigned gem