Unable to discover pre-release version of gem released months ago #4097
Comments
|
Just for the reference, this is missing from info file at rubygems.org side. I'll take a look if there is anything we can do to fix this. debug infocontent of https://rubygems.org/info/gemfury as in time of writing this comment (missing 0.13.0.beta1) and related line in https://rubygems.org/versions file at the same time (including 0.13.0.beta1) |
|
For now, I have updated info file manually (using admin panel), can you check this is fixed @pboling? Locally I can install this gem version successfully now. |
|
Yep, works now. Thanks @simi - hope the root cause can be determined and addressed! Manual processes suck! |
|
I think I have a similar case here: middleman 4.5.1 turns up on the website, is returned when querying the normal API: ...but is missing from the index: |
|
@simi I'm seeing a similar issue with |
let me take a look 👀 |
|
@evman182 I did quick check and it is present now. There was no action taken from rubygems.org. Full indexing can take a minute or two after pushing the gem. Can you confirm everything is ok? |
|
@simi No, I still do not see the v3 pre-release at https://rubygems.org/versions. This may be moreso a bug with bundler if the expectation is that bundler should fallback to fetching the gem info directly if it can't find the version in the compact index. Let me know if I should open a bug with bundler |
|
@evman182 How do you check? [retro@retro ~]❤ curl "https://rubygems.org/versions" | grep "temporal_tables 3.0.0"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 18.2M 100 18.2M 0 0 5719k 0 0:00:03 0:00:03 --:--:-- 5721k
temporal_tables 3.0.0.pre.rc.1 9ae3399947223af03c118646e5817fb2 $ ruby -r bundler/inline -e "gemfile(true) { source 'https://rubygems.org'; gem 'temporal_tables', '3.0.0.pre.rc.1' }"
# ...
Fetching temporal_tables 3.0.0.pre.rc.1
Installing temporal_tables 3.0.0.pre.rc.1 |
|
I see the line your grep found now, but why is the pre-release version on it's own line, separate from the rest of the versions? It seems like new versions are being appended to the index, instead of to their existing lines |
That's how compact index works for friendly HTTP caching purpose. It is append list (so "partial" HTTP ranged request can get file in sync without downloading whole content) and it is squashed once per month to keep it manageable long. |
|
The checksum on the newly appended line is not correct. It's the same as the old one, and doesn't match the checksum of https://index.rubygems.org/info/temporal_tables |
|
I see similar situations for other gems in the versions file. Idk if this is a new bug with compact_index or something, but I see multiple cases where the first time a gem had a version appended to the versions file, the checksum is the same as the one that was generated on 1/1/2024 |
|
@evman182 versions file doesn't include gem checksum, but something called info checksum. Everything seems ok. Sadly there is not a much documentation for those rubygems.org internals currently. Something is at https://github.com/rubygems/compact_index and older version is explained at https://andre.arko.net/2014/03/28/the-new-rubygems-index-format/. Anyway, next to those internals, do you still face any troubles running |
|
cc: @segiddins as I think this is related to your PR: #4255. I can open a new issue if you want since it appears to be unrelated to the issue I've been commenting on Yes I am still seeing issues. I really think there's a bug with rubygems.org related to this and this, which is used to gather all the versions to generate the "info checksum": rubygems.org/app/models/gem_info.rb Line 126 in c204f62 and that the query is looking for indexed = true, but with the changes in the above PR that I linked to, that indexed value isn't being set until later. If you look at this code block, that indexed attribute use to be set true on line 164, but now it's not set until the rubygems.org/app/models/pusher.rb Lines 164 to 182 in c204f62 |
|
@evman182 mind opening a new issue? I should be able to look into it tomorrow |
Describe the problem as clearly as you can
In a gemspec:
Or in a Gemfile:
NOTE: it makes no difference if
~>is added to loosen the constraint.Did you try upgrading rubygems & bundler?
Yes.
Post steps to reproduce the problem
Run
bundle install, orbundle update.What were you expecting to happen?
I expected the pre-release gem to be found and installed.
What actually happened?
The extra weird thing is that it clearly is seeing other pre-release versions for the same gem. Just not the one that was released in July.
If not included with the output of your command, run
bundle envand paste the output belowEnvironment
Bundler Build Metadata
Bundler settings
Gemfile
Gemfile
Gemfile.lock
Gemspecs
vc_ruby.gemspec
The text was updated successfully, but these errors were encountered: