| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
r=segiddins
Tweak gemspec template when using Ruby 2.x
### What was the end-user problem that led to this PR?
There are unnecessary magic comment for currently maintained Ruby 2.2, 2.3, and 2.4.
### What was your diagnosis of the problem?
The default script encoding from Ruby 2.0 is UTF-8.
https://bugs.ruby-lang.org/issues/6679
Ruby 1.9 is EOL, so I think that there is not much Gem to start developed using it.
### What is your fix for the problem, implemented in this PR?
This PR removes magic comment when starting Gem development (i.e. `bundle gem`) with Ruby 2.0 or higher version.
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
r=segiddins
Capitalize the description lines in Bundler 2
This PR is a small patch.
### What was the end-user problem that led to this PR?
I made the following changes locally to the code of the master branch and tried Bundler 2.0.
```diff
% git diff
diff --git a/lib/bundler/version.rb b/lib/bundler/version.rb
index dad4a88a2..386782023 100644
--- a/lib/bundler/version.rb
+++ b/lib/bundler/version.rb
@@ -7,7 +7,7 @@ module Bundler
# We're doing this because we might write tests that deal
# with other versions of bundler and we are unsure how to
# handle this better.
- VERSION = "1.15.1" unless defined?(::Bundler::VERSION)
+ VERSION = "2.0.0.dev" unless defined?(::Bundler::VERSION)
def self.overwrite_loaded_gem_version
begin
```
Here is the result of running the `bundle` command.
```console
% bundle
Bundler version 2.0.0.dev
Commands:
bundle add GEM VERSION # Add gem to Gemfile and run bundle install
bundle binstubs GEM [OPTIONS] # Install the binstubs of the listed gem
bundle cache [OPTIONS] # Locks and then caches all of the gems into vendor/cache
bundle check [OPTIONS] # Checks if the dependencies listed in Gemfile are satisfied by currently installed gems
bundle clean [OPTIONS] # Cleans up unused gems in your bundler directory
bundle config NAME [VALUE] # retrieve or set a configuration value
bundle doctor [OPTIONS] # Checks the bundle for common problems
bundle env # Print information about the environment Bundler is running under
bundle exec [OPTIONS] # Run the command in context of the bundle
bundle gem GEM [OPTIONS] # Creates a skeleton for creating a rubygem
bundle help [COMMAND] # Describe available commands or one specific command
bundle help [COMMAND] # Describe subcommands or one specific subcommand
bundle info GEM [OPTIONS] # Show information for the given gem
bundle init [OPTIONS] # Generates a Gemfile into the current working directory
bundle inject GEM VERSION # Add the named gem, with version requirements, to the resolved Gemfile
bundle install PLUGINS # Install the plugin from the source
bundle install [OPTIONS] # Install the current environment to the system
bundle issue # Learn how to report an issue in Bundler
bundle licenses # Prints the license of all gems in the bundle
bundle lock # Creates a lockfile without installing
bundle open GEM # Opens the source directory of the given bundled gem
bundle outdated GEM [OPTIONS] # list installed gems with newer versions available
bundle platform [OPTIONS] # Displays platform compatibility information
bundle plugin SUBCOMMAND ...ARGS # manage the bundler plugins
bundle pristine [GEMS...] # Restores installed gems to pristine condition from files located in the gem cache. Gem installed from a git reposito...
bundle show GEM [OPTIONS] # Shows all gems that are part of the bundle, or the path to a given gem
bundle update [OPTIONS] # update the current environment
bundle version # Prints the bundler's version information
bundle viz [OPTIONS] # Generates a visual dependency graph
Options:
[--no-color] # Disable colorization in output
-r, [--retry=NUM] # Specify the number of times you wish to attempt network commands
-V, [--verbose], [--no-verbose] # Enable verbose output mode
```
The beginning of the description lines are not unified with capitalized.
### What was your diagnosis of the problem?
It is the same as above.
### What is your fix for the problem, implemented in this PR?
Unify the beginning of the description lines with capitalized.
```console
% bundle
Bundler version 2.0.0.dev
Commands:
bundle add GEM VERSION # Add gem to Gemfile and run bundle install
bundle binstubs GEM [OPTIONS] # Install the binstubs of the listed gem
bundle cache [OPTIONS] # Locks and then caches all of the gems into vendor/cache
bundle check [OPTIONS] # Checks if the dependencies listed in Gemfile are satisfied by currently installed gems
bundle clean [OPTIONS] # Cleans up unused gems in your bundler directory
bundle config NAME [VALUE] # Retrieve or set a configuration value
bundle doctor [OPTIONS] # Checks the bundle for common problems
bundle env # Print information about the environment Bundler is running under
bundle exec [OPTIONS] # Run the command in context of the bundle
bundle gem GEM [OPTIONS] # Creates a skeleton for creating a rubygem
bundle help [COMMAND] # Describe available commands or one specific command
bundle help [COMMAND] # Describe subcommands or one specific subcommand
bundle info GEM [OPTIONS] # Show information for the given gem
bundle init [OPTIONS] # Generates a Gemfile into the current working directory
bundle inject GEM VERSION # Add the named gem, with version requirements, to the resolved Gemfile
bundle install PLUGINS # Install the plugin from the source
bundle install [OPTIONS] # Install the current environment to the system
bundle issue # Learn how to report an issue in Bundler
bundle licenses # Prints the license of all gems in the bundle
bundle lock # Creates a lockfile without installing
bundle open GEM # Opens the source directory of the given bundled gem
bundle outdated GEM [OPTIONS] # List installed gems with newer versions available
bundle platform [OPTIONS] # Displays platform compatibility information
bundle plugin SUBCOMMAND ...ARGS # Manage the bundler plugins
bundle pristine [GEMS...] # Restores installed gems to pristine condition from files located in the gem cache. Gem installed from a git reposito...
bundle show GEM [OPTIONS] # Shows all gems that are part of the bundle, or the path to a given gem
bundle update [OPTIONS] # Update the current environment
bundle version # Prints the bundler's version information
bundle viz [OPTIONS] # Generates a visual dependency graph
Options:
[--no-color] # Disable colorization in output
-r, [--retry=NUM] # Specify the number of times you wish to attempt network commands
-V, [--verbose], [--no-verbose] # Enable verbose output mode
```
Thanks.
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Sort all documented settings in the bundle-config man page
### What was the end-user problem that led to this PR?
The problem was we kept on adding new settings to the end of the list, making it completely unordered.
### What was your diagnosis of the problem?
My diagnosis was we should order the list.
### What is your fix for the problem, implemented in this PR?
My fix orders the list and tests that it is indeed ordered.
### Why did you choose this fix out of the possible options?
I chose this fix because I could write a little script to do it.
|
| | | | |
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
r=segiddins
Compare sources using source's root
### What was the end-user problem that led to this PR?
Given a setup where:
1. A project's Gemfile makes use of another project's Gemfile and the `eval_gemfile` method to share the dependencies. Something like:
```ruby
# project_plugin's Gemfile
eval_gemfile(File.expand_path("../../main_project/Gemfile", __FILE__))
```
2. The main project includes a path gem in it that is nested in the main project:
```ruby
# main_project's Gemfile
gem "foo_gem", :path => "vendor/foo_gem"
```
3. A `bundle install` is followed by a `bundle install --deployment`, the second of which triggers a comparison of the `lockfile.sources` and the `Bundler.definition`
A error will occur when comparing the specs, saying the the "foo_gem" source has been deleted:
```console
$ bundle install
...
$ bundle install --deployment
You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.
the gemspecs for path gems changed
You have deleted from the Gemfile:
* source: source at `../main_project/vendor/foo_gem`
```
### What was your diagnosis of the problem?
(extracted from the commit message)
When doing the following:
expand(other.original_path)
inside a `Bundler::Source::Path` instance, the `@root_path` from the instance that is having `eq?` called on it, the the `other` instance's `root_path`. This, in obscure cases, can cause a bug when you are doing an nested eval_gemfile or other calls when comparing the lockfile's locked path sources to the `Bundler.definition`'s path sources.
### What is your fix for the problem, implemented in this PR?
Use a new public method, `Bundler::Source::Path#expanded_original_path`, in the `eq?` method instead of using's the instance's `#expand` method.
### Why did you choose this fix out of the possible options?
(extracted from the commit message)
Creating the `expanded_original_path` method allows a public interface to be made available (and doesn't mess with any exiting functionality) that allows comparing the source path of one `Source::Path`'s `expand_path` to another, where each uses their own `root_path` to resolve their full path, instead of sharing the base one and causing edge case bugs
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When doing the following:
expand(other.original_path)
inside a Bundler::Source::Path instance, the `@root_path` from the
instance that is having eql? called on it, the other instance's
root_path. This, in obscure cases, can cause a bug when you are doing an
nested eval_gemfile or other calls when comparing the lockfile's locked
path sources to the Bundler.definition's path sources.
Creating the expanded_original_path method allows a public interface to
be made available (and doesn't mess with any exiting functionality) that
allows comparing the source path of one Source::Path's expand_path to
another, where each uses their own root_path to resolve their full path,
instead of sharing the base one and causing edge case bugs
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
[2.0] Enable specific_platform by default on 2.0
### What was the end-user problem that led to this PR?
The problem was that Bundler has somewhat suspect handling of multi-platform gems. We'd assume that different platform versions of gems were generally interchangeable, so if Bundler resolved to the "ruby" platform gem we'd just blindly try to swap in the gem for the local platform, which could lead to issues (say if the sets of dependencies were different).
### Was was your diagnosis of the problem?
My diagnosis was that we needed to stop only working with the notion of "generic" platforms, which mapped everything to (basically) either java, pure ruby, and windows, and instead keep track of the actual platforms a bundle was being used on, and resolve for those specific platforms.
### What is your fix for the problem, implemented in this PR?
My fix enables the changes made in https://github.com/bundler/bundler/pull/4836 by default on Bundler 2.
### Why did you choose this fix out of the possible options?
I chose this fix because it means Bundler will default to more correct platforms semantics out of the box.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Also ensure the resolver processes specs in the correct order for error messages
|
| | | | | |
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
[RemoteSpecification] Fail gracefully when deps is an array of array of string
Instead of containing Gem::Dependency objects
### What was the end-user problem that led to this PR?
The problem was some gems have invalid gemspecs served by RubyGems.org. See https://github.com/bundler/bundler/issues/5797.
### Was was your diagnosis of the problem?
My diagnosis was (very old) some gemspecs can have `s.dependencies = [["name", "req"]]` instead of `s.dependencies = [Gem::Dependency.new("name", "req")]`.
### What is your fix for the problem, implemented in this PR?
My fix coerces the invalid dependencies to an array of dependency objects so we can fail more gracefully during installation, without spitting out the error template.
Closes #5797.
### Why did you choose this fix out of the possible options?
I chose this fix because it allows resolution to finish, and falls back upon existing error messages.
|
| | | | |
| | | |
| | | |
| | | | |
string insted of containing Gem::Dependency objects
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Use the Package command for `bundle cache` on Bundler 2
### What was the end-user problem that led to this PR?
The problem was the current `bundle cache` is obsolete.
### Was was your diagnosis of the problem?
My diagnosis was we want `bundle package` to be `bundle cache`, but can't change the `cache` behavior due to backwards compatibility.
### What is your fix for the problem, implemented in this PR?
My fix is to redirect `bundle cache` to `bundle package` on Bundler 2.
### Why did you choose this fix out of the possible options?
I chose this fix because it implements https://github.com/bundler/bundler/pull/4008 without breaking the current `bundle cache` command on master.
|
| | |/ / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
r=segiddins
remove forbidden chars in cassettes pathname
### What was the end-user problem that led to this PR?
Users running Micorsoft Windows are currently unable to clone to Bundler project due to a forbidden character in the folder path:
`spec/support/artifice/vcr_cassettes/realworld/api.rubygems.org/api/v1/dependencies?gems=bundler'`
The `?` being the forbidden character.
See #5828
### What is your fix for the problem, implemented in this PR?
Replaced the forbidden character in the folder name with a `-` and updated the VCR spec helper to replace any forbidden character with a `-` in the filename function.
### Why did you choose this fix out of the possible options?
This was the most simple approach to fix the issue.
|
| | | | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
[2.0] Suppress `Using …` messages during installation when a version has not changed
### What was the end-user problem that led to this PR?
The problem was that `bundle install` output can get very verbose, even when Bundler is not doing anything.
See https://github.com/bundler/bundler-features/issues/33.
### Was was your diagnosis of the problem?
My diagnosis was that bundler was printing a bunch of `Using name (version)` messages, even when we were already using that gem at the same version.
### What is your fix for the problem, implemented in this PR?
My fix is to introduce a feature flag (enabled by default on 2.0), that will only print those extra `Using` messages when `--verbose` is passed, and will continue to print them when there was an old version we can tell users about. Note that we still print a message when installing a gem for the first time.
### Why did you choose this fix out of the possible options?
I chose this fix because it was essentially what had been done in https://github.com/bundler/bundler/pull/3872, and allows for easy feature-flagging.
|
| | | | | | | |
|
| | | |_|_|/
| |/| | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Vendor fileutils since it is now a gem
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| |\ \ \ \ \ \
| |_|_|_|/ /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Extract lockfile generation into a new class
### What was the end-user problem that led to this PR?
The problem was that eventually we might want to add more stuff to the lockfile.
### What was your diagnosis of the problem?
My diagnosis was that lockfile generation should probably exist outside of a single method.
### What is your fix for the problem, implemented in this PR?
My fix is to create a `LockfileGenerator` class.
|
| | | |/ / /
| |/| | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
[2.0] Remove the console command
### What was the end-user problem that led to this PR?
> The console command has gotten many, many pull requests for different kinds of customization and so we eventually realized that an editable bin/console is the only way to provide that level of customization. The gem command already creates bin/console, so all that's left is to remove the console command.
From https://github.com/bundler/bundler/issues/4025.
### Was was your diagnosis of the problem?
My diagnosis was `bundle console` needed to go.
### What is your fix for the problem, implemented in this PR?
My fix removes the console command behind a feature flag, enabled by default on 2.0.
See https://github.com/bundler/bundler/pull/4034.
### Why did you choose this fix out of the possible options?
I chose this fix because it didn't require touching any of the console logic and would give the proper missing command error on 2.0.
|
| | |/ / / / |
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Add a bin/bundle binstub
### What was the end-user problem that led to this PR?
The problem was that developing bundler can be difficult, and letting users use the in-development bundler locally should be as easy as possible.
### What was your diagnosis of the problem?
My diagnosis was we could use a binstub that handles setting up the load path for bundler, ensures the gem spec is activated, and loads the local bundler code.
### What is your fix for the problem, implemented in this PR?
My fix adds such a binstub.
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fix typo in pull request template
Tiny typo fix.
|
| |/ / / / |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
[2.0] [DSL] Remove default git sources on 2.0
### What was the end-user problem that led to this PR?
The problem was the default git source shortcuts have been deprecated, but still existed in 2.0.
### Was was your diagnosis of the problem?
My diagnosis was we needed to avoid adding them in 2.0.
### What is your fix for the problem, implemented in this PR?
My fix is to introduce a feature flag, which when enabled will stop adding the sources to the DSL, and additionally will disable the `github` DSL method.
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
Small documentation fixes for spelling and grammar
Hi - I had some time and ran through all the docs looking for small typos and grammatical mistakes. Please let me know if I need to fill out the CHANGELOG and/or anything else.
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
[2.0] Remove RubyGems Aggregate & support transitive source pinning
### What was the end-user problem that led to this PR?
The problem was that the resolver could resolve specs from _any_ of the sources specified in the Gemfile, even if that source had nothing to do with the spec in question. This was such a large security vulnerability that, when discovered, it warranted a CVE and its own minor release of Bundler.
Closes #3671.
Closes #3696.
Closes #4059.
### Was was your diagnosis of the problem?
My diagnosis was that we needed to get rid of the notion of a `rubygems aggregate` and enforce that specs could only come either from the source they were declared to come from (the top-level source if declared at the top-level of the Gemfile, else a scoped source), or a source that it transitively "inherited" from the gems that required it.
### What is your fix for the problem, implemented in this PR?
My fix is to disable multiple top-level sources in the Gemfile, remove the RubyGems aggregate, and filter the sources gems could come from as described above.
### Why did you choose this fix out of the possible options?
I chose this fix because it allows doing the filtering in a reasonably performant manner, and refactors the way we handle sources to abstract some of the grossness in such a way that the machinations to make sure that all of the necessary gem info is downloaded is encapsulated into a single method, driven from the definition, rather than being specific to rubygems sources.
See https://github.com/bundler/bundler/pull/4714 and https://github.com/bundler/bundler/pull/4930 for the prior implementation.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
disable_multisource
|
