Bundler update and fixes to solve Bundler dependencies

Vít Ondruch vondruch at redhat.com
Wed Nov 12 14:43:05 UTC 2014


And one additional remark, there is bug in Bundler with RubyGems 2.2+.
It does not clean the load path properly. Hopefully upstream will soon
accept the patch [1] fixing this issue.


Vít


[1] https://github.com/bundler/bundler/pull/3237



Dne 12.11.2014 v 15:25 Josef Stribny napsal(a):
> Hi all,
>
> today I updated Bundler to the latest 1.7.6 version[0] and fixed an issue with Bundler's
> dependencies[1]. Although you probably didn't come across this, the issue showed up during
> packaging Vagrant which uses Bundler underneath.
>
> As you may know Bundler actually vendors its dependencies (thor and net-http-persistent)
> in lib/bundler/vendor, but those were removed in Fedora. The problem arises when you make
> Bundler to lock the dependencies with Bundler.setup which means that Bundler clears out
> $LOAD_PATH keeping itself on the path, but without its dependencies. When the dependency
> is requested to be loaded, Bundler just adds the vendor dir on $LOAD_PATH. On Fedora
> however the vendor dir is empty and therefore Bundler cannot continue (unless the
> requested vendored library has been previously loaded into memory).
>
> The most reasonable fix was to go with symlinks to system RubyGems that are also specified
> as runtime dependencies (although missing in gemspec)[2]. The symlinks are generated after
> Bundler installation or upon removal of old Bundler's dependencies (so to say on their
> update, but after the old files are removed). This way Bundler works a little bit more
> like its upstream counterpart and doesn't break anymore.
>
> If you can, please help me to test it and let me know what you think.
>
> Best Regards
> Josef
>
>
> [0] in rawhide, builds for f21 and f20 are in updates-testing
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1163039
> [2] http://pkgs.fedoraproject.org/cgit/rubygem-bundler.git/commit/?id=b7da2ec4119f24fda9e00fad1032212f89373d07
>


More information about the ruby-sig mailing list