Open fnoop opened 4 years ago
Can do that for each versioned release. Just going to come back with each commit for working branch. And I am working from master for docs. Does that work for you?
These comments suggest to bump the version up to something high, but that doesn't work. https://github.com/rubygems/bundler-features/issues/88#issuecomment-109220888 https://github.com/rubygems/bundler/issues/3697#issuecomment-108100899
I guess the only option is either to keep manually removing it from the lockfile, or fix a version of bundler that doesn't get changed for as long as possible, so we can document it for other contributors, and can be set as a parameter in maverick manifest for the devframe docs.
Seems like a really strange thing to do - reading the comments above and lots of other similar ones not one that a lot of ruby developers agree with..
seems to be restrictive. and not clear if there is a reason, which never makes things better. right now my last local build totally locked up. and all i did was add a few images. so have to get that fixed first.
https://stackoverflow.com/questions/18383402/how-to-specify-minimum-bundler-version-for-gemfile
don't know if that helps
It's not a minimum version that's needed - it's the exact version. I had bundler 2.1.4 installed (the latest, I think, currently), but it needed exactly 2.1.2 to work. Any other version produced the same cryptic error.
When trying to build the odcs with jekyll, getting this error:
The issue is explained here: https://bundler.io/blog/2019/05/14/solutions-for-cant-find-gem-bundler-with-executable-bundle.html
Doing a system update of gem (
gem update --system
) is not a good solution - it seems to update some fundamental components enough that it sends puppet absolutely haywire and completely breaksmaverick configure
. Updating ruby is not a sensible option on most systems. The easiest fix is simply to remove the BUNDLED version in Gemfile.lock: