Two gaps in knowledge/ruby/ mean a gem without a Gemfile reports an empty package_managers array.
knowledge/ruby/bundler.toml declares files = ["Gemfile"]. Bundler also reads gems.rb, with gems.locked as its lockfile. In Bundler 4.1.0.beta1, lib/bundler/shared_helpers.rb:271 returns ["gems.rb", "Gemfile"] as the search list, line 32 maps gems.rb to gems.locked, and line 148 warns when both are present because gems.rb takes precedence. Adding gems.rb to [detect] files, and gems.locked alongside the existing [config] entries, covers that layout.
Separately, there is no package_manager entry for RubyGems anywhere under knowledge/ruby/. A *.gemspec is a gem's own manifest, and knowledge/ruby/language.toml already detects the Ruby language from it, but nothing reports a package manager. So a gemspec-only gem, a gems.rb user, and a Hoe-style gem with neither file all come back with no package manager detected. knowledge/ocaml/opam.toml shows the glob form this needs: files = ["*.opam", "**/*.opam", "opam"]. Whether RubyGems belongs as its own tool definition or as additional detection on Bundler is a judgement call, though they are different tools: Bundler resolves dependencies, RubyGems builds and installs the gem.
This matters for consumers that route on package-manager detection. A gem in a monorepo sub-folder ships its .gemspec while the Gemfile sits at the repository root, so brief run against the sub-path reports no package manager. scrutineer selects its per-ecosystem container image from that field and falls back to an image with no Ruby interpreter. alpha-omega-security/scrutineer#1100 is the downstream symptom and the workaround being considered there, which would be unnecessary if the gemspec case produced a package-manager detection.
Two gaps in
knowledge/ruby/mean a gem without aGemfilereports an emptypackage_managersarray.knowledge/ruby/bundler.tomldeclaresfiles = ["Gemfile"]. Bundler also readsgems.rb, withgems.lockedas its lockfile. In Bundler 4.1.0.beta1,lib/bundler/shared_helpers.rb:271returns["gems.rb", "Gemfile"]as the search list, line 32 mapsgems.rbtogems.locked, and line 148 warns when both are present becausegems.rbtakes precedence. Addinggems.rbto[detect] files, andgems.lockedalongside the existing[config]entries, covers that layout.Separately, there is no
package_managerentry for RubyGems anywhere underknowledge/ruby/. A*.gemspecis a gem's own manifest, andknowledge/ruby/language.tomlalready detects the Ruby language from it, but nothing reports a package manager. So a gemspec-only gem, agems.rbuser, and a Hoe-style gem with neither file all come back with no package manager detected.knowledge/ocaml/opam.tomlshows the glob form this needs:files = ["*.opam", "**/*.opam", "opam"]. Whether RubyGems belongs as its own tool definition or as additional detection on Bundler is a judgement call, though they are different tools: Bundler resolves dependencies, RubyGems builds and installs the gem.This matters for consumers that route on package-manager detection. A gem in a monorepo sub-folder ships its
.gemspecwhile theGemfilesits at the repository root, so brief run against the sub-path reports no package manager. scrutineer selects its per-ecosystem container image from that field and falls back to an image with no Ruby interpreter. alpha-omega-security/scrutineer#1100 is the downstream symptom and the workaround being considered there, which would be unnecessary if the gemspec case produced a package-manager detection.