| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
- 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.
|
| |
|
| |
|
|
|
|
| |
Also forces all installs through the parallel_installer to ensure consistency.
|
| |
|
|
|
|
| |
closes #3854
|
|
|
|
| |
closes #3850
|
| |
|
| |
|
|
|
|
|
| |
Because its faster and okay since all specs with the same name were
already filtered out.
|
|
|
|
|
|
| |
Reject is clearly not the right method to use here, now I’m trying to
figure out what state of mind I was in when I wrote something that is
so obviously wrong.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
It seems like some really bad build instability started with these
changes. This isn't a straight revert, because I accidentally mixed
changes to outdated into the original commit, but this reverts all the
parallel installer changes.
Reverts some of 'a467f7d1f4ded46a519c1f211a75de70c21bc647'.
|
|
|