Currently, some warning messages don't contain a `URI` like the following.
```ruby
warning: URI::ABS_URI is obsolete. Use RFC2396_PARSER.regexp[:ABS_URI] explicitly.
```
But, without `URI` prefix, the suggested value doesn't work.
So I think we should use a fully qualified name to avoid confusion.
428eb10e44
I want to add new node types to the parser translator, for example `itblock`. The bulk of the work is already done by prism itself. In the `parser`
builder, this would be a 5-line change at most but we don't control that here.
Instead, we can add our own builder and either overwrite the few methods we need,
or just inline the complete builder. I'm not sure yet which would be better.
`rubocop-ast` uses its own builder for `parser`. For this to correctly work, it must explicitly choose to extend the
prism builder and use it, same as it currently chooses to use a different parser when prism is used.
I'd like to enforce that the builder for prism extends its custom one since it will lead to
some pretty weird issues otherwise. But first, I'd like to change `rubocop-ast` to make use of this.
b080e608a8
This message is printed when running `bundle lock --add-platform`. This
command affects the lockfile, not the gemfile, and I think it's better
to use "You are adding" rather than "You added", because the addition is
happening during the current invocation (as opposed to other log
messages that talk about a change made to the Gemfile prior to running
the command).
aba1e55f5b
- ### Problem
Running `bundle doctor` warn about files that aren't writable.
This makes the output of `bundle doctor` very verbose for something
I believe isn't really an issue.
### Context
Rubygems keeps the files original permission at the time the gem
is packaged.
Many gem maintainers have decided that the permissions of the files
in their bundled would be 0444, this includes amongst others:
minitest, selenium, brakeman...
Any git gems that had a 0444 permissions at some point in its git
history would also be reported (as bundle doctor look in the
`cache/bundler/git/<gem>/object` path).
While it completely make sense to report when files aren't readable,
maybe it's worth questioning the usefulness of reporting files
that can't be written and what problem this causes to the user
(if any).
### Solution
Removed the check for unwritable file.
### Side note
I also tweaked the "No issues ..." message logic as it was doing
the opposite (reporting an issue when there is none and vice versa).
This wasn't caught in tests because as a stub on `Bundler.ui.info`
was missing.
9a426b9495
As long as there's nothing new to install and gems are already there.
If not, give a meaningful error about what happened.
This was how things already worked until
345ec45f5a, so this commit partially
reverts that change.
794b0ecb39
When working with our repository on JRuby locally, I get the following
changes when running `bin/rake setup` in all of our lockfiles
```diff
diff --git a/tool/bundler/dev_gems.rb.lock b/tool/bundler/dev_gems.rb.lock
index 74550b2a40 100644
--- a/tool/bundler/dev_gems.rb.lock
+++ b/tool/bundler/dev_gems.rb.lock
@@ -66,6 +66,7 @@ PLATFORMS
java
ruby
universal-java
+ universal-java-22
x64-mingw-ucrt
x86-linux
x86_64-darwin
```
This is inconvenient, so I applied the same strategy we already use on
non JRuby implementations to not add the current platform to the
lockfile if a less specific platform is already there.
812b9cd1e8
Unfortunately this requires reverting a previous enhancement of
reinstalling gems if they incorrectly ship with an empty installation
dir.
However, there's no way to distinguish this kind of bad state from a gem
that's empty for real, for example, sorbet-static-and-runtime.
This reverts commit 9720a9b980, and adds a
spec to make sure empty gems are not reinstalled every time.
7c102394af
There's no reason to call `converge_specs` when adding additional
lower bound requirements to prevent downgrades, and it actually causes
the extra requirements to be missed sometimes.
Loop over the originally locked specs directly, adding the additional
precaution of not adding the requirement if the Gemfile dependency has
changed and it no longer matches the locked spec.
5154506912
Resolver had internal logic to prioritize locked versions when sorting
versions, however part of it was not being actually hit because of how
unlocking worked in the resolver: a package was allow to be unlocked
when that was explicit requested or when the list of unlocks was empty.
That did not make a lot of sense and other cases were working because
the explicit list of unlocks was getting "artificially filled".
Now we consider a package unlocked when explicitly requested (`bundle
update <package>`), or when everything is being unlocked (`bundle
install` with no lockfile or `bundle update`).
This makes things simpler and gets the edge case added as a test case
working as expected.
b8e55087f0
Bundler does not really have a concept of "development dependencies",
like RubyGems has. Bundler has the more generic concept of "groups".
Under the hood, the `gemspec` DSL will put gemspec development
dependencies under a `:development` Gemfile group, but there's no reason
to instantiate these as development dependencies, they are regular
runtime dependencies, except that they belong in a group named
:development.
By never instantiating development dependencies at all, we avoid having
to introduce hacks to "undo" the type Bundler does not know about, and I
also think the error messages read better.
9a06fa5bda
We have a flaky failure where to equal Bundler specs sneak into the same
SpecSet. This seems like a vector where that could happen so trying this
in case it fixes the flaky.
a33aeb3c4d
