- The command can either be run using:
1. `bundle doctor --ssl`
2. `bundle doctor ssl`
The later is most useful when you need to specify
custom ssl options (such as the verify mode or the
TLS version when running the diagnostic).
The implementation will follow in the next commits.
993d12874c
- Adding a new `ssl` option to bundle doctor will make the `Doctor`
command quite bloated. The "diagnose ssl" option will also have
children option to allow passing which host or which tls version
you want to diagnose and I feel these options don't belong in the
doctor command.
So my intention in this commit is to prepare to have a new `Doctor`
subcommand and allow for better organisation of the code:
The command will be:
`bundle doctor` -> Run exactly the same as before.
`bundle doctor --ssl` -> Run the doctor command and diagnose SSL
with default options (rubygems.org as the host and verify peer as
the verify mode)
`bundle doctor ssl --host github.com` -> Run the ssl subcommand and
pass a specific host.
This commit just renames a file in order to avoid big diff chunks.
In frozen mode, the previous logic would not set the platform locked
originally in the materialized specification, and that would trigger the
warning about insecure materialization incorrectly.
a18001e10c
If both a native and a generic version are locked, but the native
version is incompatible with the running Ruby, Bundler will still keep
the native version in the lockfile, since it could be potentially useful
when using other rubies.
However, when `bundle update` is run, this was not the case because the
locked native gems were not using the right source when materializing.
They were using the lockfile source instead of the Gemfile source, and
that meant they could not be found when materializing, because the
lockfile source always uses local mode so does not see them.
The effect of this was normally that they were incorrectly removed from
the lockfile and a strange "this spec has been possibly yanked" was
printed in verbose mode. However, in certain situations (i.e., when the
generic gem would bring extra dependencies), it could also make `bundle
update` crash.
The solution is, when adding this extra locked specs to the result after
resolving, maybe sure they inherit the source from the resolved specs,
so they can be found when materializing.
`bundle install` did not have the issue because it passes locked specs
to the resolver, and assigns the right source to them in
`Definition#converge_locked_specs`.
91ce881fda
mutable constants can't be shared across ractors; this changes that design to define the required variables as constants on the Resource class, which makes them reachable using ractors; the ClassHash is kept in order not to break integrations relying on its existence, but under the hood it's doing the same thing
639c01dc7f
* Explicitly recommend copying full command output and not just the bug
report template part.
* Include quadruple quotes in the "What actually happened section" and
tell users to copy full command output inside. Hopefully quadruple
quotes will make the error report information (which includes triple
quotes itself) render fine by default.
* Avoid "actually" as per quality_spec.rb recommendation.
0a3bf2edb1
Because it ends up treating it as a local variable, and `a.x`
is not a valid local variable name.
I'm not big on pattern matching, but conceptually it makes sense to me
to treat anything inside ^() to not be
pattern matching syntax?
80dbd85c45
That restores support for compact index dummy implementations that only lists
versions, without checksums or dependencies.
This format is undocumented, so we may want to get rid of it in the
future. However, some of our tests rely on it, and some implementations
did use it (gems.mutant.dev at least). And the way the code was written
suggest that support was intentional.
So for now, we should restore it.
0427d8c983
Instead, remove them anytime we find dependencies don't match the
lockfile for a platform, and then add them back after resolution if
they ended up being valid.
220bd77887
`StringNode` and `SymbolNode` don't have the same shape
(`content` vs `value`) and that wasn't handled.
I believe the logic for the common case can be reused.
I simply left the special handling for implicit nodes in pattern matching
and fall through otherwise.
NOTE: patterns.txt is not actually tested at the moment,
because it contains syntax that `parser` mistakenly rejects.
But I checked manually that this doesn't introduce other failures.
https://github.com/whitequark/parser/pull/106055adfaa895
My application spends more than 30% of time during `bundle update`
comparing versions due to versions being sorted inside
next_package_to_try. This has been addressed in pub_grub by defining a
strategy interface (a `#next_package_and_version` method) which allows
consumers to have finer control over the heuristic to select the next
package to try.
This commit implements the new strategy interface to remove extraneous
version sorting (previously in next_package_to_try) since only the final
count of versions is used.
Combined with a previous change to pub_grub (already applied to
Bundler), this commit results in `bundle update` taking only half the
time it did on 2.6.5.
62f69e27f0
Instead of doing an explicit pass to preserve the source from the
Gemfile when it's a `Source::Gemspec`, add a special case to our generic
source replacement method.
20c8c42380
