This repository has been archived by the owner on Apr 14, 2021. It is now read-only.
bundle package recursive loop when using multiple gemspecs #4430
Comments
|
I switched to 1.12.0.rc and it still goes into the recursion loop. |
|
@jsmilani don't use |
|
If you could provide us with a reproduction case for this problem, we would be happy to fix it, however! |
|
@indirect Unfortunately as of 1.12.0.rc the local path still attempts to put in vendor/cache and recursion loop still happens. I will create a sample repo that can reproduce the problem. |
|
https://github.com/jsmilani/bundler_recursion Check that out and run "bundle package --all" with current stable bundler or 1.12.0.rc |
|
Thanks @jsmilani, I can reproduce this! |
homu
added a commit
that referenced
this issue
Apr 14, 2016
…p-with-multiple-gemspecs, r=segiddins Handle recursive bundle package loop when multiple gemspecs present `root_gem_names` should contain the names of the gems that the gemspecs in the directory are correlated with. Gems are packaged unless they're called `bundler` or their names match with the gems specified in the gemspecs. - Handles multiple gemspecs in directory - Handles case where gemspec file name does not match with the gem name specified in the gemspec - Fixes #4430
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I am attempting to run 'bundle package' during a deploy of our repo, but when we do we get a recursion loop during the cp_r ending with the error: "Errno::ENAMETOOLONG: File name too long @ rb_sysopen - /Users/me/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/localizer/vendor/cache/support_rb-4a8c0775d668/.git/objects/pack/pack-13658d6ae3c302c3932bfb35ee087a28ed30533a.idx"
I have narrowed the problem down to our second gemspec in our repo that we use for a client library. When we leave it in bundler wants to package our repo inside of itself and it falls into an recursion loop until the filename gets too long and fails. Fortunately the second second '-client' gemspec is not necessary for deployments and 'bundle package' works when I comment out that line, but I have not found any way to 'bundle package' without commenting it out.
The ideal way to solve this is to have bundler look at the path of the gem it wants to package and reject it if it is the same as the project root directory. I welcome other suggestions for temporary fixes until then.
Example Gemfile:
The text was updated successfully, but these errors were encountered: