| Age | Commit message (Collapse) | Author |
|
https://github.com/rubygems/rubygems/commit/ccb65ce0ea
|
|
https://github.com/rubygems/rubygems/commit/feb258c712
|
|
For consistency with the other deprecations.
https://github.com/rubygems/rubygems/commit/28e300cee1
|
|
https://github.com/rubygems/rubygems/commit/444022cfd3
|
|
(https://github.com/ruby/erb/pull/74)
https://github.com/ruby/erb/commit/125ce1f897
|
|
(https://github.com/ruby/erb/pull/73)
https://github.com/ruby/erb/commit/04bb746fc7
|
|
(https://github.com/ruby/erb/pull/71)
https://github.com/ruby/erb/commit/f4abab7195
|
|
(https://github.com/ruby/erb/pull/72)
https://github.com/ruby/erb/commit/df7bdcd5cb
|
|
https://github.com/ruby/erb/commit/aae3a5be34
|
|
It's a term from times with multiple remote sources, let's move on :)
https://github.com/rubygems/rubygems/commit/6439b8944e
|
|
https://github.com/rubygems/rubygems/commit/8f9d6c54a1
|
|
https://github.com/rubygems/rubygems/commit/1bc5e74281
|
|
https://github.com/rubygems/rubygems/commit/4c110d3289
|
|
https://github.com/rubygems/rubygems/commit/0a2f5ed717
|
|
Before this patch we would use `IO.copy_stream` with the tar entry
object rather than just straight to the IO. That means every time
copy_stream wanted data, we would have to proxy the call.
The reason we did this is because every tar entry object _shares_ the
same IO object, and previous to https://github.com/rubygems/rubygems/commit/8927533b0a47
we would call `IO.copy_stream` _without_ a size. Without passing a
size, copy_stream will just read until there is nothing left to read, so
these proxy object emulate finding "the end of the file" (where "end of
file" means "end of tar chunk"). Without emulating this "end of file"
behavior, copy_stream would just keep reading past the end of the tar
chunk.
However, now that we're passing the size to copy_stream, we can bypass
the proxy object overhead and just use the IO object directly because
copy_stream knows exactly the number of bytes it needs to read and will
stop when it reaches the goal.
https://github.com/rubygems/rubygems/commit/857002c135
|
|
And let the feature always be enabled, so I'm not sure why we'd need
this configurable.
https://github.com/rubygems/rubygems/commit/5a27f0c1e3
|
|
If the CLI flags are used, we abort early as usual.
As per the settings, I decided to ignore them. We've been migrating them
automatically to the new name for a long time and we don't yet have a
standard way to deprecate and remove settings (we should probably use
the existing setting validators). So I think it's fine for now to do
what we normally do (ignore the setting).
https://github.com/rubygems/rubygems/commit/8311de6e69
|
|
https://github.com/rubygems/rubygems/commit/2c16b0e11e
|
|
In Bundler 4, configuration will no longer be updated.
https://github.com/rubygems/rubygems/commit/33a4718d7a
|
|
When extracting tar files, the tar header actually knows the exact size
of the file we need to extract. Before this commit, we would read the
file from the tar file until it returned `nil`. We can be a little more
efficient when copying by passing the size to copy_stream
https://github.com/rubygems/rubygems/commit/8927533b0a
|
|
We already have the open file descriptor, so we can avoid the overhead
of resolving the filepath (as well as the overhead inside `FileUtils`)
by just calling `chmod` on the file descriptor itself.
https://github.com/rubygems/rubygems/commit/60c14bbeee
|
|
(https://github.com/ruby/erb/pull/69)
* [DOC] More on class
ERB
* [DOC] More on class
ERB
* More
* More
* More
https://github.com/ruby/erb/commit/d9d73ed58e
|
|
Symbol#name is only a thing since Ruby 3.0
https://github.com/ruby/prism/commit/2de82b15fc
|
|
The performances are: block > proc > method object.
https://github.com/ruby/optparse/commit/9ec5d1d582
|
|
An unspecified uplevel is not the same as an uplevel of 1:
```
$ irb
irb(main):001> warn("foo")
foo
=> nil
irb(main):002> warn("foo", uplevel: 1)
/home/user/.rbenv/versions/2.7.8/lib/ruby/gems/2.7.0/gems/irb-1.14.0/lib/irb/workspace.rb:121: warning: foo
=> nil
```
https://github.com/ruby/prism/commit/dcedd14357
|
|
(https://github.com/ruby/erb/pull/68)
https://github.com/ruby/erb/commit/9591b5d23b
|
|
Make it clear that it parses with the most recent version of Ruby
syntax.
https://github.com/ruby/prism/commit/7285d1fbab
|
|
https://github.com/ruby/prism/commit/cac5118884
|
|
(https://github.com/ruby/erb/pull/67)
https://github.com/ruby/erb/commit/7646ece279
|
|
https://github.com/ruby/prism/commit/194edab827
|
|
changes
When the source used to be git and switches back to rubygems,
it is possible that the git source contains a version that
ruybgems doesn't know about yet.
So don't add the locked spec to the base resolve, and also don't add a
lower bound requirement on the version, since the version in the new
source may actually be lower.
https://github.com/rubygems/rubygems/commit/85514e3a1e
|
|
It matches the comment above more naturally and it's consistent with how
the same thing is checked in other places.
https://github.com/rubygems/rubygems/commit/59ec6b4b29
|
|
It sounds like this should apply to all git sources at this point.
https://github.com/rubygems/rubygems/commit/b1817f91de
|
|
https://github.com/rubygems/rubygems/commit/744b35412e
|
|
If the file option is given but the file not found, raise a GemfileError
with a message indicating the file was not found.
Currently this is raising a generic Errno::ENOENT error.
https://github.com/rubygems/rubygems/commit/db61de6b21
|
|
The same also applies to `break`/`next`.
https://bugs.ruby-lang.org/issues/21540
https://github.com/ruby/prism/commit/3a38b192e3
|
|
(https://github.com/rubygems/rubygems/pull/8904)
* Added document for Gem::Uninstaller
* Apply suggestion from @deivid-rodriguez
Co-authored-by: David Rodríguez <2887858+deivid-rodriguez@users.noreply.github.com>
---------
https://github.com/rubygems/rubygems/commit/9aeec8721a
Co-authored-by: David Rodríguez <2887858+deivid-rodriguez@users.noreply.github.com>
|
|
https://github.com/rubygems/rubygems/commit/573ffad3ea
|
|
https://github.com/rubygems/rubygems/commit/825e29a9ec
|
|
https://github.com/rubygems/rubygems/commit/f5bf473b34
|
|
`vlad` entrypoints
Now they only raise an error.
https://github.com/rubygems/rubygems/commit/6e7c8db151
|
|
`Bundler.environment` helpers
https://github.com/rubygems/rubygems/commit/e1b8bdcede
|
|
Probably due to the testing order, sometimes it looks like that
`Gem::UnknownCommandError` happens to be used without registered in
`DidYouMean`.
|
|
the same gem in Gemfile
https://github.com/rubygems/rubygems/commit/e47a9064be
|
|
control
--append adds a source to the end, moving it to the end if it already exists.
--prepend adds or moves a source to the beginning.
This allows idempotent sorting of gem sources without removing and adding.
https://github.com/rubygems/rubygems/commit/d9a0567c65
|
|
Since Ruby 3.4.5, which ships with did_you_mean-2.0.0, RubyGems no
longer gives "did you mean" suggestions for unknown commands.
This is because did_you_mean-2.0.0 completely removed the SPELL_CHECKERS
constant, and attaching "did you mean" to `Gem::UnknownCommandError`
errors required this constant to be defined.
The fix is to remove conditions on the `SPELL_CHECKERS` constant.
https://github.com/rubygems/rubygems/commit/9287cd80ed
|
|
only configured sources
https://github.com/rubygems/rubygems/commit/ef78de5b69
|
|
sources`
"Not present in cache" felt a bit unclear, so I changed the reason to:
"No configured sources" or "source not present in configured sources",
also pointing explicitly to the configuration file where RubyGems is
looking for the source to be removed.
https://github.com/rubygems/rubygems/commit/2bae554eff
|
|
https://github.com/rubygems/rubygems/commit/0ccf323734
|
|
https://github.com/rubygems/rubygems/commit/d86d9b3596
|