Add --gemfile flag to bundle init to configure gemfile name to generate

[gustavothecoder]

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

When running bundle init with BUNDLE_GEMFILE, the gemfile name is still the original (Gemfile) instead of the custom defined in BUNDLE_GEMFILE.

For more details, see the issue #6016.

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

The main problem here is that Bundler#preferred_gemfile_name doesn't consider the BUNDLE_GEMFILE config, so my first change was adjust this method to use the BUNDLE_GEMFILE when necessary. I changed the method to give priority to the init_gems_rb config, so if user uses both init_gems_rb and BUNDLE_GEMFILE, the first one will be used. I decide to make this way to preserve the original behavior, but I'm not sure if this approach is ideal and I would like to know what you guys think. I think that we'll need to update the docs with this behavior, by the way.

The second change I made was to adjusting the init command to use some template when BUNDLE_GEMFILE is used. This was necessary because the template is chosen based on the gemfile name and the current implementation doesn't consider the case where the gemfile has a custom name. I noticed that all available templates has the same content, is it feasible to merge them into a single template? Because that would simplify the code a bit.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[deivid-rodriguez]

Thank you @gustavothecoder!

Any opinions on what the behavior should be if the BUNDLE_GEMFILE set already exists? Should we keep the current behavior with a warning in that case? @dentarg what do you think?

[gustavothecoder]

Thank you @gustavothecoder!

Any opinions on what the behavior should be if the BUNDLE_GEMFILE set already exists? Should we keep the current behavior with a warning in that case? @dentarg what do you think?

You mean when the user sets the BUNDLE_GEMFILE using the bundle config? I think we should use the BUNDLE_GEMFILE defined in runtime.

[dentarg]

Any opinions on what the behavior should be if the BUNDLE_GEMFILE set already exists? Should we keep the current behavior with a warning in that case? @dentarg what do you think?

I think we should exit with error saying the file already exists, like we do today

[deivid-rodriguez]

Some environments have a fixed BUNDLE_GEMFILE, and on top of that, when bundle exec is run, BUNDLE_GEMFILE is fixed to the current Gemfile for the subprocess. Also, Bundler generated binstubs set BUNDLE_GEMFILE right at the top.

I'm afraid this may break bundle init processes inside user scripts due to the above.

That's why I was suggesting a warning if BUNDLE_GEMFILE has a non default, existing, value, and fallback to the current behavior of creating a file named Gemfile.

[dentarg]

So BUNDLE_GEMFILE=foo bundle exec <script that calls "bundle init"> should still create Gemfile (but also print a warning)? Well, I have no strong feelings about that but really, not something I'm gonna do I think, and I like the spirit of keeping backwards compatibility, but... what the hell :) If I encountered it, I would find the behaviour a bit funny I think, but I guess it makes sense considering past behaviour.

[deivid-rodriguez]

Yes, in these simple examples feeding BUNDLE_GEMFILE directly, it feels a bit dumb, but sometimes things are messy/complicated and it's actually hard to tell how/where/what set/exported BUNDLE_GEMFILE in the first place.

[gustavothecoder]

Just to confirm if I understand correctly. When BUNDLE_GEMFILE already exists and is different from the default gemfile name, we'll print a warning and create another gemfile with the default name (Gemfile), that's it?

[deivid-rodriguez]

@gustavothecoder Yes, that's my suggestion.

[gustavothecoder]

@deivid-rodriguez I think it's working fine now:

demo.mp4

[deivid-rodriguez]

Looks good!

I was also thinking that warnings should be actionable, so we should clearly explain to users how to fix the warning.

The solution would be to pass BUNDLE_GEMFILE=Gemfile explicitly to the subcommand, but depending on the situation it might not be so easy, maybe we should add a explicit --gemfile flag to bundle init?

Or maybe this is all a bit overkill and I'm overthinking this. I'd like to hear opinions from other maintainers.

[dentarg]

maybe we should add a explicit --gemfile flag to bundle init?

That makes sense to me. I have actually looked for it, and I almost thought I found it 😆 but then I noticed that it said --gemspec 😓

[gustavothecoder]

maybe we should add a explicit --gemfile flag to bundle init?

That makes sense for me too, but, are we going to support both BUNDLE_GEMFILE and --gemfile?

@deivid-rodriguez what do you think of this message?: "Bundler will name the gemfile "Gemfile" because foo already exists at /some/dir/foo. To silence this warning, run bundle init --gemfile Gemfile."

[deivid-rodriguez]

@gustavothecoder Sorry for the lack of feedback.

Based on the discussion, I think the easiest approach here may be to add a --gemfile option and don't change anything regarding BUNDLE_GEMFILE here, i.e., ignore it like we've been doing till now?

[gustavothecoder]

@gustavothecoder Sorry for the lack of feedback.

Based on the discussion, I think the easiest approach here may be to add a --gemfile option and don't change anything regarding BUNDLE_GEMFILE here, i.e., ignore it like we've been doing till now?

That make sense. I'll change the fix.

[gustavothecoder]

@deivid-rodriguez do you think we can improve the implementation?

[deivid-rodriguez]

Sorry for the lack of feedback here @gustavothecoder, I'll try to review this soon.

[deivid-rodriguez]

Looks mostly ready, just one more comment.

Thanks for your infinite patience here, I think it was this long discussion because this approach finally seems the simplest way to go to me!

[deivid-rodriguez]

We currently have two gemfile templates: gems.rb and Gemfile, but they have the same content. I think we can use ../templates/Gemfile unconditionally here and remove the gems.rb template and the template_path method?

[gustavothecoder]

We can. I'll do it.

[deivid-rodriguez]

Looks great, just one more small comment but I'll fix it myself when rebasing this! Thanks so much @gustavothecoder!