-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Calling bundle install with BUNDLE_WITH runtime env var persists it in .bundle/config #3708
Comments
Hi @mokagio! I just read this and it seems like a bug to me, since all my expectations here match yours. I'll try to find some time to repro and hopefully fix it. |
Hey @deivid-rodriguez 👋 That's awesome! I checked out Full output
Pretty cool how a refactor ended up fixing a bug. Proof of the value of looking after code quality 💪 ! Thank you so much for looking into this promptly. I'll leave it up to you whether to close this issue now or wait till 2.2.0 is out. |
Yay! 🎉 I'm glad it works! I think I'll close this now, because I'm going to forget to do it when we release :) Thanks for the great report and your kind words! |
Bundler 2.2.0 contains a fix for an issue with optional groups and the `.bundle/config` file. The issue resulted in the file being touched every time we'd run a `BUNDLE_WITH=screenshots bundle install` with a change that, if tracked, would have required all developers to set up all the screenshots automation tooling while that's only needed by platforms developers. See rubygems/rubygems#3708
Hey @deivid-rodriguez 👋 I just tried this with Bundler 2.2.5, experienced the issue again. I think I tracked it down to #4154. I run The rationale of my expectation is that calling a CLI tool with an env var is a way to bypass existing configurations. After chatting with @SViccari on Twitter I wonder if my expectation is incorrect 🤔 Can you shed some light on this? And do let me know if there's anything I can do to help solving this. Thanks 🙌 |
Ha! @mokagio My expectations are the same as yours, that's why I fixed this issue initially. However, I had forgotten about this issue. When I got reports about the fix for this issue causing trouble for users, I thought the PR where I fixed this was just something annoying that I found out about, and didn't link it to this bug report. So I decided to temporarily revert it. Anyways, the idea here is to go with #4152, and then reapply the fix that was reverted since it will no longer cause issues. |
See discussion here: #292 (comment) To ensure the setting is persisted for every user of the repository, I decided to track the Bundler config file. This seems like a good idea anyway, even though Bundler currently has a bug resulting in that file being changed sometimes, which can be confusing for developers. See rubygems/rubygems#3708
See discussion here: #292 (comment) To ensure the setting is persisted for every user of the repository, I decided to track the Bundler config file. This seems like a good idea anyway, even though Bundler currently has a bug resulting in that file being changed sometimes, which can be confusing for developers. See rubygems/rubygems#3708
I had to revert the fix to this bug, but I never reopened it. |
@deivid-rodriguez no worries at all! You folks have released a bajillion versions in the meantime, thank you for all the improvements and fixes that came along the way. 🙇♂️ |
This version fixes an issue that could have created confusion when running `BUNDLE_WITH=screenshots bundle install` would result in an automated change to `.bundle/config`. See rubygems/rubygems#3708 (comment)
This version fixes an issue that could have created confusion when running `BUNDLE_WITH=screenshots bundle install` would result in an automated change to `.bundle/config`. See rubygems/rubygems#3708 (comment)
This version fixes an issue that could have created confusion when running `BUNDLE_WITH=screenshots bundle install` would result in an automated change to `.bundle/config`. See rubygems/rubygems#3708
I checked all the following documents and couldn't find a solution for my issue:
1. Do you have a reproduction script?
https://gist.github.com/mokagio/7dfcd75ffc2fac278c2bde4862c3164b
2. What are you trying to accomplish?
We use some Ruby tooling across the Automattic iOS apps. We want to achieve two things:
vendor/bundle
Gemfile
, which should be used only by platforms devs and CI.This setup results in an unexpected change to the
.bundle/config
when installing the optional group, more on it below.The need for the optional group is because we use
rmagick ~> 3.2.0
, which requires an older version of ImageMagick. We don't want the product devs to have to worry about setting up their machine correctly to support it.3. What command did you run?
In order to make sure gems are vendored, I tried to track
.bundle/config
in the repo.In order to install the optional group, I run
4. What were you expecting to happen?
I was expecting the installation to be successful, including the gem in the optional group, and no change to occur in
.bundle/config
.The installation was successful, including the gem in the optional group, but
.bundle/config
changed, like this:--- BUNDLE_PATH: "vendor/bundle" +BUNDLE_WITH: "optional_group"
I wasn't expecting that. My understanding of environment variables is that they can be used to override configurations at runtime. I don't understand why
bundle install
updated its config file with the environment value I passed it.Using
bundle install --with optional_group
, which is a deprecated approach, has the same result.The docs say:
The practical implication of this is the -admittedly minor- issue that if a dev needs to do work locally with the gems in the optional group, they need to remember not to commit the changes to
.bundle/config
.In the case of our setup, if a dev ends up committing the change to
.bundle/config
, the CI job running the unit tests will try to installrmagick
and fail because the machine it runs on is not provisioned with ImageMagick. Again, this is a minor issue, but I'm still unsure whether the resulting change in the.bundle/config
is a feature or a bug.6. Is there an exception backtrace?
No.
7.
bundle env
Details
Environment
Bundler Build Metadata
Bundler settings
Gemfile
Gemfile
Gemfile.lock
Thank you for taking the time to read my report (and hopefully respond 😅).
I've been using Bundler for 10 years, almost on a daily basis. This is the first time I find myself opening an issue. I think this proves how much of a great and robust tool this is. Thank you to all the team and contributors for the great effort you put in it. 💖
The text was updated successfully, but these errors were encountered: