Skip to content
This repository has been archived by the owner on Apr 14, 2021. It is now read-only.

BUNDLE_GEMFILE does not override .bundle/config path to Gemfile #6270

Closed
joelvh opened this issue Jan 24, 2018 · 6 comments
Closed

BUNDLE_GEMFILE does not override .bundle/config path to Gemfile #6270

joelvh opened this issue Jan 24, 2018 · 6 comments
Labels
type: bug report

Comments

@joelvh
Copy link
Contributor

joelvh commented Jan 24, 2018

It's possible to specify a development version of the Gemfile in .bundle/config (such as Gemfile.dev). However, when running something like BUNDLE_GEMFILE=Gemfile bundle exec rake will still use Gemfile.dev.

Shouldn't the environment variable override what's specified in .bundle/config?
@joelvh
Copy link
Contributor Author

joelvh commented Jan 24, 2018

Would love to submit a PR for this, but spent a lot of time trying to track down where the Gemfile path is determined and haven't been able to identify the proper fix yet....

@colby-swandale
Copy link
Member

This seems like a bug, thanks for the report! A PR would be awesome! I suggest looking at SharedHelpers as you'll find most of the logic around finding the Gemfile there.

@joelvh
Copy link
Contributor Author

joelvh commented Jan 24, 2018 •
edited
Loading

@colby-swandale I see there's an "environment preserver" here, and it seems to copy the environment variable I'm trying to pass over to BUNDLER_ORIG_BUNDLE_GEMFILE.

https://github.com/bundler/bundler/blob/2c059142d17df414ab6f06842cfbfd7321a3e33e/lib/bundler.rb#L21

It looks like this is also related, which either takes a CLI option --gemfile or pulls from settings. I think environment variables should be merged into settings. (My specific issue is trying to specify BUNDLE_GEMFILE with bundle update, so adding the --gemfile option for bundle update could suffice... I don't know why it's not already an option for that command. However, it's not intuitive that the environment variables don't override settings.)

https://github.com/bundler/bundler/blob/master/lib/bundler/cli.rb#L36

@joelvh joelvh mentioned this issue Jan 24, 2018
Merged
@joelvh
Copy link
Contributor Author

joelvh commented Jan 31, 2018

@colby-swandale this is my original issue which identified that environment variables do not override .bundle/config settings because it seems the environment variables are "backed up" and replaced with default values before settings are loaded.

Rather than trying to run BUNDLER_GEMFILE=Gemfile bundle update when .bundle/config specifies Gemfile.dev as the default Gemfile, I opted to implement the --gemfile option to mimic bundle install --gemfile in #6273.

Any interest in keeping this issue open to fix the root cause which prevents environment variables from overriding .bundle/config?

@colby-swandale
Copy link
Member

👍 this issue needs to also be fixed as well.

bundlerbot added a commit that referenced this issue Jan 31, 2018
@bundlerbot
Auto merge of #6273 - joelvh:feature/bundle_update_gemfile_option, r=…
a0592e5 
…colby-swandale

Added `--gemfile` option to `bundle update`

Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.

### What was the end-user problem that led to this PR?

The problem was that `BUNDLE_GEMFILE` is not respected when `.bundle/config` specifies an alternate Gemfile. However, my specific issue is that `bundle install --gemfile Gemfile2` is an option, but `bundle update` won't let me specify an alternate Gemfile.

### What was your diagnosis of the problem?

My diagnosis was that Bundler copies `BUNDLE_GEMFILE` environment variable to `BUNDLE_ORIG_GEMFILE` and always uses `.bundle/config`. Simplest solution was to add parity to `bundle update` rather than diagnose why environment variables don't override `.bundle/config` settings across the board.

### What is your fix for the problem, implemented in this PR?

My fix is to add the `--gemfile` option to `bundle update` for parity with `bundle install`.

### Why did you choose this fix out of the possible options?

I chose this fix because this allows installing and updating alternative Gemfiles without untangling environment variables. It's the most direct use case that I'm having this issue with.

Ideally, the environment variables specified for a command should be respected and override settings in `.bundle/config` (#6270).
@agrim123 agrim123 mentioned this issue Mar 7, 2018
Closed
@colby-swandale
Copy link
Member

So looking into this issue further, this is actually intended behavior of Bundler (to my surprise). The local configuration takes precedent over ENV. I'm going to open a new issue on working to provide better information on the order that Bundler looks at settings. Apologies for not picking this up sooner.

I'm going to close this issue.

@colby-swandale colby-swandale mentioned this issue Mar 9, 2018
Closed
@rubymorillo rubymorillo mentioned this issue Mar 28, 2018
Merged
bundlerbot added a commit that referenced this issue Mar 28, 2018
@bundlerbot
Auto merge of #6464 - bundler:rubymorillo-patch-3, r=colby-swandale
8b8b963 
Document the order Bundler loads settings

Parsed out the information in the first graph in order to help users understand the order of priority Bundler follows when loading config settings.

Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.

### What was the end-user problem that led to this PR?

The problem was...
...[confusion from end users](#6270) about the order that Bundler loads settings in.

Before:
```
This command allows you to interact with bundler's configuration system.
Bundler retrieves its configuration from the local application (`app/.bundle/config`),
environment variables, and the user's home directory (`~/.bundle/config`),
in that order of priority.
```

### What was your diagnosis of the problem?

My diagnosis was...
...[Colby pointed out how the bundle-config doc](#6334) needed to be updated to reflect this. After reviewing the `bundle-config` doc, it appears there was some information about how Bundler loads config settings, but it wasn't complete and as apparent to users. So I decided to separate the graph out and document the settings as a list so users could spot that easier.

### What is your fix for the problem, implemented in this PR?

My fix...
...was to verify the order of priority of settings and write them out as a list.

After:
```
This command allows you to interact with Bundler's configuration system.

Bundler loads configuration settings in this order:

1. Local config (`app/.bundle/config`)
2. Environmental variables (`ENV`)
3. Global config (`~/.bundle/config`)
4. Bundler default config
```

### Why did you choose this fix out of the possible options?

I chose this fix because...
it was clear that the document had to be updated, and lists are easier for readability.

fixes #6334
colby-swandale pushed a commit that referenced this issue Apr 11, 2018
@bundlerbot @colby-swandale
Auto merge of #6464 - bundler:rubymorillo-patch-3, r=colby-swandale
4209fe2 
Document the order Bundler loads settings

Parsed out the information in the first graph in order to help users understand the order of priority Bundler follows when loading config settings.

Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.

### What was the end-user problem that led to this PR?

The problem was...
...[confusion from end users](#6270) about the order that Bundler loads settings in.

Before:
```
This command allows you to interact with bundler's configuration system.
Bundler retrieves its configuration from the local application (`app/.bundle/config`),
environment variables, and the user's home directory (`~/.bundle/config`),
in that order of priority.
```

### What was your diagnosis of the problem?

My diagnosis was...
...[Colby pointed out how the bundle-config doc](#6334) needed to be updated to reflect this. After reviewing the `bundle-config` doc, it appears there was some information about how Bundler loads config settings, but it wasn't complete and as apparent to users. So I decided to separate the graph out and document the settings as a list so users could spot that easier.

### What is your fix for the problem, implemented in this PR?

My fix...
...was to verify the order of priority of settings and write them out as a list.

After:
```
This command allows you to interact with Bundler's configuration system.

Bundler loads configuration settings in this order:

1. Local config (`app/.bundle/config`)
2. Environmental variables (`ENV`)
3. Global config (`~/.bundle/config`)
4. Bundler default config
```

### Why did you choose this fix out of the possible options?

I chose this fix because...
it was clear that the document had to be updated, and lists are easier for readability.

fixes #6334

(cherry picked from commit 8b8b963)
colby-swandale pushed a commit that referenced this issue Apr 20, 2018
@bundlerbot @colby-swandale
Auto merge of #6464 - bundler:rubymorillo-patch-3, r=colby-swandale
f1001d5 
Document the order Bundler loads settings

Parsed out the information in the first graph in order to help users understand the order of priority Bundler follows when loading config settings.

Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.

### What was the end-user problem that led to this PR?

The problem was...
...[confusion from end users](#6270) about the order that Bundler loads settings in.

Before:
```
This command allows you to interact with bundler's configuration system.
Bundler retrieves its configuration from the local application (`app/.bundle/config`),
environment variables, and the user's home directory (`~/.bundle/config`),
in that order of priority.
```

### What was your diagnosis of the problem?

My diagnosis was...
...[Colby pointed out how the bundle-config doc](#6334) needed to be updated to reflect this. After reviewing the `bundle-config` doc, it appears there was some information about how Bundler loads config settings, but it wasn't complete and as apparent to users. So I decided to separate the graph out and document the settings as a list so users could spot that easier.

### What is your fix for the problem, implemented in this PR?

My fix...
...was to verify the order of priority of settings and write them out as a list.

After:
```
This command allows you to interact with Bundler's configuration system.

Bundler loads configuration settings in this order:

1. Local config (`app/.bundle/config`)
2. Environmental variables (`ENV`)
3. Global config (`~/.bundle/config`)
4. Bundler default config
```

### Why did you choose this fix out of the possible options?

I chose this fix because...
it was clear that the document had to be updated, and lists are easier for readability.

fixes #6334

(cherry picked from commit 8b8b963)
@rlue rlue mentioned this issue May 14, 2018
Closed
colby-swandale pushed a commit that referenced this issue Sep 20, 2018
@bundlerbot @colby-swandale
Auto merge of #6273 - joelvh:feature/bundle_update_gemfile_option, r=…
ebdcabf 
…colby-swandale

Added `--gemfile` option to `bundle update`

Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.

### What was the end-user problem that led to this PR?

The problem was that `BUNDLE_GEMFILE` is not respected when `.bundle/config` specifies an alternate Gemfile. However, my specific issue is that `bundle install --gemfile Gemfile2` is an option, but `bundle update` won't let me specify an alternate Gemfile.

### What was your diagnosis of the problem?

My diagnosis was that Bundler copies `BUNDLE_GEMFILE` environment variable to `BUNDLE_ORIG_GEMFILE` and always uses `.bundle/config`. Simplest solution was to add parity to `bundle update` rather than diagnose why environment variables don't override `.bundle/config` settings across the board.

### What is your fix for the problem, implemented in this PR?

My fix is to add the `--gemfile` option to `bundle update` for parity with `bundle install`.

### Why did you choose this fix out of the possible options?

I chose this fix because this allows installing and updating alternative Gemfiles without untangling environment variables. It's the most direct use case that I'm having this issue with.

Ideally, the environment variables specified for a command should be respected and override settings in `.bundle/config` (#6270).

(cherry picked from commit a0592e5)
colby-swandale pushed a commit that referenced this issue Oct 5, 2018
@bundlerbot @colby-swandale
Auto merge of #6273 - joelvh:feature/bundle_update_gemfile_option, r=…
2e4bae5 
…colby-swandale

Added `--gemfile` option to `bundle update`

Thanks so much for the contribution!
To make reviewing this PR a bit easier, please fill out answers to the following questions.

### What was the end-user problem that led to this PR?

The problem was that `BUNDLE_GEMFILE` is not respected when `.bundle/config` specifies an alternate Gemfile. However, my specific issue is that `bundle install --gemfile Gemfile2` is an option, but `bundle update` won't let me specify an alternate Gemfile.

### What was your diagnosis of the problem?

My diagnosis was that Bundler copies `BUNDLE_GEMFILE` environment variable to `BUNDLE_ORIG_GEMFILE` and always uses `.bundle/config`. Simplest solution was to add parity to `bundle update` rather than diagnose why environment variables don't override `.bundle/config` settings across the board.

### What is your fix for the problem, implemented in this PR?

My fix is to add the `--gemfile` option to `bundle update` for parity with `bundle install`.

### Why did you choose this fix out of the possible options?

I chose this fix because this allows installing and updating alternative Gemfiles without untangling environment variables. It's the most direct use case that I'm having this issue with.

Ideally, the environment variables specified for a command should be respected and override settings in `.bundle/config` (#6270).

(cherry picked from commit a0592e5)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
type: bug report
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add check for BUNDLE_GEMFILE in cli agrim123/bundler
2 participants
@joelvh @colby-swandale