| Age | Commit message (Collapse) | Author |
|
Picked from https://github.com/rubygems/rubygems/commit/4b498709a015a94e14a3852a1841a7a3e669133d
|
|
Previously, the command string to be used for the shell command
was first generated and then split using shellsplit. This change
reverts the current behavior as it breaks if the value of remote
contains a space.
https://github.com/rubygems/rubygems/commit/6649ee10b0
|
|
https://github.com/rubygems/rubygems/commit/a54cca13db
|
|
https://github.com/rubygems/rubygems/commit/6a5a80eff7
|
|
https://github.com/rubygems/rubygems/commit/f328ef6f77
|
|
So that system man pages still work after a gem with man pages overrides
it.
https://github.com/rubygems/rubygems/commit/1031879b87
|
|
Calling `Bundler.definition.specs` will memoize materialized specs.
However, requiring `bundler/setup` will end up materializing the same
set of specs, but not memoize them.
This change makes things consistent.
https://github.com/rubygems/rubygems/commit/e4c2b52824
|
|
present
https://github.com/rubygems/rubygems/commit/28f4842196
|
|
Co-authored-by: Frederik Dudzik <frederik.dudzik@shopify.com>
Co-authored-by: Jacques Chester <jacques.chester@shopify.com>
|
|
Rescuing all errors here might end up hiding other errors if the
deletion of the cached gem itself raises an error for some reason. Let's
be more conservative.
https://github.com/rubygems/rubygems/commit/3d80dfba08
|
|
Even if it's newer than the running versions. Dev versions are not
released to rubygems.org, so the warning message suggests a command that
doesn't work. And dev versions are currently non deterministic
(2.3.0.dev can be many different versions), so the warning doesn't
really make sense at the moment.
https://github.com/rubygems/rubygems/commit/6f31af27ef
|
|
As noticed by @nobu https://github.com/rubygems/rubygems/pull/4989#discussion_r735674633
From wikipedia: https://en.wikipedia.org/wiki/SHA-1#SHA-1_pseudocode
> append ml, the original message length in bits, as a 64-bit big-endian integer.
`Q` is native endian, so little-endian on most modern hardware.
The original code from RubyDigest reverses the bytes:
https://github.com/Solistra/ruby-digest/blob/d15f906caf09171f897efc74645c9e31373d7fd1/lib/ruby_digest.rb#L521
But that makes the code non-portable, the correct way is to directly ask
for a big-endian representation.
https://github.com/rubygems/rubygems/commit/ba2be01ea4
|
|
Some crucial information to ease maintainers work, like the advice of
upgrading rubygems and bundler, was one step away from the issue
template, making it easier for some users to miss.
Now all relevant information is written directly in the bug report
template.
|
|
can't be deleted
Instead of showing the bug report template with an error at a random
place.
https://github.com/rubygems/rubygems/commit/882ad3ab57
|
|
Instead of showing the bug report place with an error at a randome
place.
https://github.com/rubygems/rubygems/commit/241854ce73
|
|
searching it
https://github.com/rubygems/rubygems/commit/d0df25bb0f
|
|
Previously, it was maintained in sync with the standard cache. That was
less efficient, and it caused some error messages to point to non
existent files.
https://github.com/rubygems/rubygems/commit/931f8cb8a9
|
|
https://github.com/rubygems/rubygems/commit/83b2b845b3
|
|
We can skip most stuff in `Gem::RemoteFetcher#download`, and use
`Gem::RemoteFetcher#update_cache_path` directly.
This has the benefit of allowing us to remove some workarounds to
support several rubygems versions, but also allows us to pass the target
folder where the gem should be downloaded directly and skip the logic
inside `Gem::RemoteFetcher#download` to infer the cache path. This will
be useful later to fix some issues with the `global_gem_cache` feature
flag.
https://github.com/rubygems/rubygems/commit/8fe74a77e4
|
|
https://github.com/rubygems/rubygems/commit/3c93b9fd21
|
|
These methods rescue a constant defined by `rubygems/remote_fetcher`,
so they should technically require it.
The require is provided by `gem_remote_fetcher` anyways but I was
running a unit spec that stubs that method, so I was getting an
undefined constant error hiding another error.
https://github.com/rubygems/rubygems/commit/8bedae4034
|
|
https://github.com/rubygems/rubygems/commit/13b933f49a
|
|
https://github.com/rubygems/rubygems/commit/8319305d58
|
|
Extract final cache path to a variable and pass that to `download_gem`.
It actually fits better the parameters documentation since it's the
final directory where the downloaded gem will be placed.
https://github.com/rubygems/rubygems/commit/1429db6a04
|
|
This allows `Source::Git` to no longer load the `digest` gem as it is causing
issues on Ruby 3.1.
https://github.com/rubygems/rubygems/pull/4989/commits/c19a9f2ff7
|
|
When `install_with_build_args` was added in
https://github.com/rubygems/rubygems/commit/be96283985cb49c023112117b2ac2dea0d9becf1,
there were two versions of the method: the default version in the base class that still
used the locking `with_build_args`, and an override in the `Future`
class (for Rubygems 2.0 and up) that yielded without calling
`with_build_args`.
The `with_build_args` version of the method was removed in
https://github.com/rubygems/rubygems/commit/8a5b71e3e8072c64a0f3cab838ba330f5e87e37a
while removing a bunch of the old Rubygems compatibility code.
This commit removes `with_build_args`, since it no longer appears to be
used (the build args are passed as a keyword argument to
`spec.source.install` instead, since
https://github.com/rubygems/rubygems/commit/be96283985cb49c023112117b2ac2dea0d9becf1).
The commit also removes `install_with_build_args` and the conditional
around it, since the method wasn't doing anything different than
`install`, and it had a comment that was no longer accurate.
https://github.com/rubygems/rubygems/commit/ba543a60eb
|
|
I am not sure why this flag was turned off (it wasn't explained in my commit message in 0365dc852767ae589376a7aad1fb129738e408b0 or in my PR in #4411).
Whatever the reason, without `default_ignores` turned on, most default CI configurations will immediately fail, as they most likely vendor and cache their dependencies under `vendor`, which will cause standard to run against all the vendored gems and (most likely) fail. I think we should remove this before this feature is released.
https://github.com/rubygems/rubygems/commit/677f74be48
|
|
Bundler::Fetcher::CertificateFailureError
https://github.com/rubygems/rubygems/commit/11b5d479cb
|
|
https://github.com/rubygems/rubygems/commit/97241e0ea4
|
|
https://github.com/rubygems/rubygems/commit/32aa540163
|
|
This method always receives an array, and we require `shellwords`
unconditionally at the top of the file, so `shelljoin` will always be
available.
https://github.com/rubygems/rubygems/commit/05c8ac641d
|
|
https://github.com/rubygems/rubygems/commit/c218d4d79e
|
|
Previously they were printing the original command that was run, and
telling the user to rerun it. However, the command sometimes would not
match the exact command that was run (for example, when using the
`--local` flag), and in any case, it's simpler and more useful to print
the underlying error anyways.
https://github.com/rubygems/rubygems/commit/5bc0d51b58
|
|
incomplete resolve
In case we have a corrupted lockfile that claims to support a platform, but
it's missing platform specific gems for it, bundler has a check that
detects the situation and forces a re-resolve. The result of this check
is kept under the `@locked_specs_incomplete_for_platformn` instance
variable in `Definition`.
The installer, however, calls `Definition#nothing_changed?` before this
instance variable has been filled, so the result of it is actually
incorrect here since it will claim that nothing has changed, but
something has changed (locked specs are incomplete for the current
platform).
The consequence of this incorrect result is that the installer thinks it
can go on without re-resolving, resulting in the incomplete resolution
from the lockfile being used, and in a crash being triggered due to
that.
The solution is to make sure the `@locked_specs_incomplete_for_platform`
instance variable is filled before `nothing_changed?` gets called.
Moving it to `initialize` makes the most sense, not because it's the
best place for it (we can refactor this later), but because all of the
other "outdated definition" checks are already set there.
https://github.com/rubygems/rubygems/commit/708afdd789
|
|
This is exclusively about the lockfile.
https://github.com/rubygems/rubygems/commit/d6c6d040cd
|
|
https://github.com/rubygems/rubygems/commit/7326d47530
|
|
It doesn't really need converged specs, since it's only about the
lockfile.
https://github.com/rubygems/rubygems/commit/9cd6224b5e
|
|
https://github.com/rubygems/rubygems/commit/8950631f02
|
|
The other way, in particular matching a substring in the gemspec
summary, is brittle and no longer used since Ruby 2.0.
This needed rewriting the specs that depended on that way.
https://github.com/rubygems/rubygems/commit/059dbfa971
|
|
All supported rubygems versions implement this.
https://github.com/rubygems/rubygems/commit/2130782ef6
|
|
https://github.com/rubygems/rubygems/commit/ff86cd7dd2
|
|
If a non exact name (matched as a regexp) is passed to `bundle info`,
these strings might not match.
https://github.com/rubygems/rubygems/commit/831edf1edf
|
|
In 2021, Ruby 2.5 and older are EOL.
We can set the default required Ruby version to 2.6.0 to
encourage people to use newer Ruby.
If the command is executed with old Ruby, it falls back to 2.3.0.
It's still possible to create a gem for older Ruby just by changing
two lines of code (one in gemspec and another is in rubocop.yml).
|
|
The glob information was not specified in the string representation for
a source, which led to non-deterministic behaviour when generating the
lockfile, since sources are sorted by this value.
https://github.com/rubygems/rubygems/commit/493b880abc
|
|
Just like all the other tasks using the `built_gem_path`, the `:build`
task is a prerequisite for this task too.
https://github.com/rubygems/rubygems/commit/d193f9a7f9
|
|
example.com is the canonical stand in for domain examples and will never have a backing website.
via https://www.rfc-editor.org/rfc/rfc2606.html
https://github.com/rubygems/rubygems/commit/26622c81c2
|
|
Closes https://github.com/rubygems/rubygems/issues/4889
https://github.com/rubygems/rubygems/commit/2b1754479c
|
|
https://github.com/rubygems/rubygems/commit/9978b787a0
Notes:
Merged: https://github.com/ruby/ruby/pull/4789
|
|
Same reason as in the previous commit.
https://github.com/rubygems/rubygems/commit/f00a6c8516
Notes:
Merged: https://github.com/ruby/ruby/pull/4789
|
|
https://github.com/rubygems/rubygems/commit/95326f827c
Notes:
Merged: https://github.com/ruby/ruby/pull/4789
|