| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
Due to the way rubygems monkey-patched require interacts with default
gems, and given that bundler is a default gem, and that bundler
manipulates the LOAD_PATH in very intricated ways, we can reduce the
risk of "leaking" to a different copy of `bundler` by using
`require_relative` for internal requires.
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add registered plugin events for before-all, before, and after gem install
Depends on #6548
### What was the end-user problem that led to this PR?
We only had one plugin hook, which limited the plugin's capabilities a lot.
This adds more
### What was your diagnosis of the problem?
We need more plugin hooks for gem stuff
### What is your fix for the problem, implemented in this PR?
Add more hooks in after-all (including dependencies) and before/after (including install spec)
### Why did you choose this fix out of the possible options?
These seemed like the obvious spots to put the hooks, but I could be wrong. The passed objects also seem to include all the info we need to action on the installations (errors, etc)
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
|
| |
The error-message function did not provide an explicit source,
and that could lead in some confusion especially with big Gemfiles.
The command that is output, should be valid.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Style/EmptyLinesAroundExceptionHandlingKeywords
- Style/SpaceAroundOperators
- Style/SpaceInsideBlockBraces
- Lint/DuplicateMethods
- Lint/Void
- Style/IfUnlessModifier
- Style/MixinGrouping
- Style/NestedParenthesizedCalls
- Style/OrAssignment
- Style/RedundantParentheses
- Style/TernaryParentheses
|
| |
|
| |
|
|
|
|
| |
This should make them nearly as fast a bundle check
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[ParallelInstaller] Show require tree when a gem fails to install due to corrupted lockfile
### What was the end-user problem that led to this PR?
The problem was that when installation failed due to a corrupted lockfile or checksum mis-match, we wouldn't show the reason that gem was being installed in the first place, as we would when other errors happened.
See https://github.com/bundler/bundler/issues/5846
### What was your diagnosis of the problem?
My diagnosis was we needed to show that requirement tree whenever installation fails, regardless of the reason for the failure.
### What is your fix for the problem, implemented in this PR?
My fix rescues hard installation errors and re-raises with the tree appended.
|
| |
| |
| |
| | |
corrupted lockfile
|
|/ |
|
|
|
|
| |
installation fails
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
okkez:fix-frozen-string-literal-error-with-rubygems-2.6.8, r=segiddins
Use empty array when `spec_settings` returns `nil`
If use bundler 1.14.4 with rubygems 2.6.8 and
`Bundler.settings["build.#{spec.name}"]` returns `nil` then we get
error "can't modify frozen literal string" from [rubygems](https://github.com/rubygems/rubygems/blob/v2.6.8/lib/rubygems/ext/rake_builder.rb#L13).
RubyGems 2.6.8 is the default version for Ruby2.4.0.
See also https://github.com/sickill/rainbow/issues/48
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If use bundler 1.14.4 with rubygems 2.6.8 and
`Bundler.settings["build.#{spec.name}"]` returns `nil` then we get
error "can't modify frozen literal string" from rubygems[1].
RubyGems 2.6.8 is the default version for Ruby2.4.0.
[1]: https://github.com/rubygems/rubygems/blob/v2.6.8/lib/rubygems/ext/rake_builder.rb#L13
See also https://github.com/sickill/rainbow/issues/48
|
|/ |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
[GemInstaller] Allow installing extensions in parallel
I believe this closes #4684
\c @lynnco
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
Unlock sources when a local override leads to changes
Closes #4838.
Requires tests
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
|
|
|
| |
Fixes #4274
|
| |
|
|\
| |
| |
| |
| | |
RochesterinNYC/improve-error-message-invalid-gemspec-for-dependency
Add helpful invalid gemspec error message for `bundle install --standalone`
|
| |
| |
| |
| | |
--standalone` when a gem/dependency has an invalid gemspec
|
|/ |
|
| |
|
| |
|
|
|
|
|
| |
- Part of design direction to move more functionality out of the
`Bundler` top-level module.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
perspective the main part is:
1. Install
2. Generate stubs
3. Print message to the user
(4. handle exceptions)
While working on it I found that Bundler::Installer's run method and
instance variables weren't used when installing gems with
install_gem_from_spec. The installer was (and still is) only used to
generate executable stubs.
So I inserted the new GemInstaller in ParallelInstaller; passing the
instantiated Bundler::Installer to the GemInstaller only to generate
the executable stubs.
Based on this I would continue by extracting two BinstubGenerator
classes and removing GemInstaller's dependency on Bundler::Installer,
possibly allowing for a more concise way to generate binstubs in other
parts of bundler.
I was a bit intimidated by the amount of installers and weary to add
another one to this contested namespace. So I checked in with
@indirect who approved of the general direction of the refactoring and
suggested to rename the old GemInstaller to RubyGemsGemInstaller.
|
| |
|
|
|
|
| |
Outdent access modifiers like private
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I wanted to fix some minor Rubocop issues and got confused by
'#{ruby_engine}/#{ruby_version}'. I managed to confuse two other people
working on bundler as well, so I decided to refactor the part around it.
I wanted to encapsulate the file creation, so it's (even) more obvious
from the context that another ruby file is created. So having an
uninterpolated string with interpolation syntax in it isn't so unusual.
To be extra sure I added a comment here as Rubocop might lead others to
the same spot.
I found that Standalone works quite well as its own object. While
extracting the class I shortened some expressions and extracted methods
that made sense as a unit to me. I ended up with a generate method that
only deals with file output.
What I think might be controversial:
* The tendency to use methods instead of variables for small things like
version_dir and bundler_path:
I think it's easier to understand because methdos are "read_only",
while values of variables might change during code execution.
* Array(spec.require_paths) instead of
"next if spec.require_paths.nil? # builtin gems".
We lose the comment here, but I thought Array was more concise and
that the information about the type of gems isn't crucial here.
* flat_map { map { ... } } instead of "collecting" in paths
My perspective is that paths is the result of a transformation of
@specs and that's best expressed by using map. It's also shorter.
|
| |
|