Age | Commit message (Collapse) | Author |
|
[Misc #21143]
Conceptually this makes sense and is more consistent with using
the `Name = Class.new(Superclass)` alternative method.
However the new class is still named before `inherited` is called.
Notes:
Merged: https://github.com/ruby/ruby/pull/12927
|
|
https://github.com/ruby/ruby/actions/runs/13804651931/job/38616664529?pr=12911
|
|
Co-authored-by: David Rodríguez <[email protected]>
|
|
If a custom rubygems source URI is long enough, Bundler may end up
raising an `ENAMETOOLONG` error and crash.
This commit fixes the problem by trimming the cache slug size to fit
usual OS requirements.
https://github.com/rubygems/rubygems/commit/df40ff1e14
Co-authored-by: mbclu <[email protected]>
Co-authored-by: martinemde <[email protected]>
|
|
https://github.com/rubygems/rubygems/commit/d28f9b8515
|
|
Because it does not swallow errors if it fails to remove the given
folders, making issues easier to debug.
https://github.com/rubygems/rubygems/commit/0db12d7afc
|
|
This has the following benefits:
* Avoid duplicated work in some specs that first build a repo, and then
overwrite it with a completely different set of gems.
* Reduce RSpec nesting and improve readability.
* The change also made surfaces several specs that were incorrect since
they were unintentionally not testing the right thing.
https://github.com/rubygems/rubygems/commit/ed430883e0
|
|
This gets our daily Bundler CI back to green.
https://github.com/rubygems/rubygems/commit/1bb70f75d2
Notes:
Merged: https://github.com/ruby/ruby/pull/12890
|
|
https://github.com/rubygems/rubygems/commit/1c237a4c3f
Notes:
Merged: https://github.com/ruby/ruby/pull/12890
|
|
https://github.com/rubygems/rubygems/commit/bd42c840c6
Notes:
Merged: https://github.com/ruby/ruby/pull/12890
|
|
only the '.git' directory is present. This recovers cases where a git-sourced install can be left in a partially installed state.
https://github.com/rubygems/rubygems/commit/d132b7008d
Notes:
Merged: https://github.com/ruby/ruby/pull/12890
|
|
https://github.com/rubygems/rubygems/commit/ba5a62fd04
Notes:
Merged: https://github.com/ruby/ruby/pull/12890
|
|
https://github.com/rubygems/rubygems/commit/9691097036
Notes:
Merged: https://github.com/ruby/ruby/pull/12890
|
|
This reverts commit 750e6195040ec3f9d0b172ac1a49a49d9b7d8ba0.
Notes:
Merged: https://github.com/ruby/ruby/pull/12890
|
|
This reverts commit 261f8023842b6f90007df68dfc3d88a01a9337a2.
Notes:
Merged: https://github.com/ruby/ruby/pull/12890
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12879
|
|
Fix: https://github.com/ruby/spec/issues/1249
JRuby and TruffleRuby can't implement this behavior.
While quite a lot of code out there relies on it, if it's
not implemented it will simply result in sligthly less efficient
code, so not the end of the world.
Notes:
Merged: https://github.com/ruby/ruby/pull/12850
|
|
https://github.com/rubygems/rubygems/commit/b4a8bda811
|
|
https://github.com/rubygems/rubygems/commit/d2f90a81d9
|
|
https://github.com/rubygems/rubygems/commit/fafb9ae090
|
|
|
|
erb is only working with Ruby 3.5dev.
|
|
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12821
|
|
If we fail to write the lockfile, give a better error.
https://github.com/rubygems/rubygems/commit/81a08d6eda
|
|
The message from dlerror is not our concern.
|
|
|
|
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).
https://github.com/rubygems/rubygems/commit/aba1e55f5b
Notes:
Merged: https://github.com/ruby/ruby/pull/12804
|
|
not in lockfile
Current it says "you added a new platform to your gemfile", but that's
not actually the case here.
https://github.com/rubygems/rubygems/commit/1e39527a38
Notes:
Merged: https://github.com/ruby/ruby/pull/12804
|
|
aren't writable:
- ### 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.
https://github.com/rubygems/rubygems/commit/9a426b9495
Notes:
Merged: https://github.com/ruby/ruby/pull/12804
|
|
Notes:
Merged-By: ioquatix <[email protected]>
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/12790
|
|
protected folders
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
https://github.com/rubygems/rubygems/commit/345ec45f5a87, so this commit partially
reverts that change.
https://github.com/rubygems/rubygems/commit/794b0ecb39
|
|
https://github.com/rubygems/rubygems/commit/24d4281d86
|
|
https://github.com/rubygems/rubygems/commit/677e17aa2e
|
|
being created
https://github.com/rubygems/rubygems/commit/f2f2ac9680
|
|
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 https://github.com/rubygems/rubygems/commit/9720a9b980d2, and adds a
spec to make sure empty gems are not reinstalled every time.
https://github.com/rubygems/rubygems/commit/7c102394af
|
|
Real gems hardly ever do this, so don't do it ourselves for testing
either.
https://github.com/rubygems/rubygems/commit/2c8960cfb4
|
|
Also, Binding#local_variable_get and #local_variable_set rejects an
access to numbered parameters.
[Bug #20965] [Bug #21049]
Notes:
Merged: https://github.com/ruby/ruby/pull/12746
|
|
Sometimes security reports believe they have found a vulnerability
because they find a domain we don't own being used in the rubygems
repository. Though there is nothing vulnerable about using 'fake'
domains in tests when they are never hit, it nonetheless reduces
confusion for everyone if we constrain our test domains to domains
we actually own and control.
https://github.com/rubygems/rubygems/commit/e77ebbe2fc
|
|
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.
https://github.com/rubygems/rubygems/commit/5154506912
|
|
To make it consistent with the spec above it.
https://github.com/rubygems/rubygems/commit/9a00bf8db9
|
|
are incorrect
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.
https://github.com/rubygems/rubygems/commit/b8e55087f0
|
|
https://github.com/rubygems/rubygems/commit/ffabab65f2
|
|
https://github.com/rubygems/rubygems/commit/8cbe6573b4
|
|
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.
https://github.com/rubygems/rubygems/commit/9a06fa5bda
|
|
And avoid installing any gems.
https://github.com/rubygems/rubygems/commit/c12700c7e4
|
|
Bundler DSL, in favor of using `platform :windows`
This commit is only deprecation and does not change/remove any actual functionality.
https://github.com/rubygems/rubygems/commit/0ca6dc3984
|
|
https://github.com/rubygems/rubygems/commit/aee52d2874
Co-authored-by: johnnyshields <[email protected]>
|
|
Otherwise it doesn't work as expected and it may skip specs.
https://github.com/rubygems/rubygems/commit/d6af077174
|