munola 0.5.0 → 0.5.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 3fef04df27a6176d9c98ef6a96588ab444f63e92a6ef3c3c3fd73268af931de3
-  data.tar.gz: 8190ecb25656352775ea9ead33c18e04c7faddaac23d67644045398fea80ce26
+  metadata.gz: 634f7369a35be4b04097f3539bdf6c41b0419836242450170c07d0937de85c76
+  data.tar.gz: 916ec77f29fefc76fabb0229c10078677ba01407d02fa02e71dd6973933961a2
 SHA512:
-  metadata.gz: 7524cf02ef40ba7136a5ff531ffda09c2e1056b9a53b73710728be0ad64a7158d3aeccf94492a7401619776d2a44a07e22bcff7511ac775083112de200df4820
-  data.tar.gz: fcf9fc3d4ac887817ad8dab39f5c071d4569a282a12fa2720bd5f935da62a4793e6a833c45032cead51f653603baf675f78f2f064351a8bae23516f912a9e883
+  metadata.gz: 044d6b03723fe94d321d1024927e9691c82cdf5a763aecd9a64709b6c4e6ffab4cb92b1555a15e812e7647b496cd1852f7d5dfb7cb3e470a789a64b0851be7f5
+  data.tar.gz: 2dc4d4e98eb5d60d948913b0dd3c69bb93077f372e76b4eddc11e2d5f96091cf7e32c7c9ded1759c1e5b96f6d5783d11a87459bea58f95cf43d874b866b2c56d

data/CHANGELOG.md

@@ -1,3 +1,38 @@
+## enola 0.5.2, enola-rb 0.5.2, munola 0.5.2 and munola-rb 0.5.2 (2026-08-23)
+
+Rubydex is off in the config these gems write, and named in a comment beside
+the reason. The release each gem drives carries a walk that can fail to
+return: a constant reference spanning lines could be treated as its own
+predecessor, so a tree with vendored gems could snapshot for twenty-six
+minutes and several gigabytes without finishing. Two of the three Rails trees
+it was tried on did exactly that.
+
+The fix exists and is not yet in a published enola, so the default cannot
+depend on it. Prism is unaffected and stays on: it parses a monolith in 13.7
+seconds. Uncommenting the two lines brings Rubydex back for anyone who wants
+it deliberately, and the default returns the moment the binary each gem drives
+carries the fix.
+
+## enola 0.5.1 (2026-08-23)
+
+The resolver no longer probes its own binstub. It read a candidate's first 512
+bytes looking for the marker RubyGems writes, and a real binstub carries a
+`/bin/sh` + `ruby -x` preamble holding the interpreter's absolute path, which puts
+that marker around byte 580 — outside the window. So the guard missed every
+RubyGems-generated binstub, the wrapper ran itself, and running itself has no
+bottom: `enola --version` on a cold cache spawned Ruby processes until it was
+killed. The whole file is read now, capped at 64 KiB so a released binary is never
+slurped only to be rejected, and `Gem.bin_path` is recognised beside
+`Gem.activate_bin_path`. A probe also marks its child's environment, and a resolver
+that sees the marker declines to look at PATH at all, so the recursion is bounded
+by construction rather than by how well a heuristic reads a file.
+
+The marker is written where it is spawned: every probe passes it into the child,
+so a wrapper reached under another name leaves PATH alone instead of probing in
+turn. That bound is what covers the wrappers the content check cannot see, a
+version manager's shim among them, which carries none of the markers a binstub
+does. Reported and fixed by dejo1307 in #1.
+
 ## munola 0.4.4.2 and munola-rb 0.4.4.2 (2026-08-23)
 
 munola follows the channel it drives. Its binary is now cut from the stable

data/lib/munola/providers_config.rb

@@ -27,7 +27,10 @@ module Munola
       else
         lines << "  # prism: the enola gem on this machine carries no provider script; add one here to run it"
       end
-      lines += ["  - name: rubydex", "    expected_version: \"#{RUBYDEX_VERSION}\""]
+      lines += ["  # rubydex is off until the channel release carries the walk fix:",
+        "  # a reference spanning lines could be its own predecessor, so a tree with",
+        "  # vendored gems could snapshot without ever finishing. Uncomment to run it.",
+        "  # - name: rubydex", "  #   expected_version: \"#{RUBYDEX_VERSION}\""]
       "#{lines.join("\n")}\n"
     end
 

data/lib/munola/version.rb

@@ -5,5 +5,5 @@ module Munola
   # CHANNEL_VERSION the fork release the gem fetches.
   UPSTREAM_VERSION = "0.4.4"
   CHANNEL_VERSION = "0.4.4.2"
-  VERSION = "0.5.0"
+  VERSION = "0.5.2"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: munola
 version: !ruby/object:Gem::Version
-  version: 0.5.0
+  version: 0.5.2
 platform: ruby
 authors:
 - Muhamed Isabegovic
@@ -53,14 +53,21 @@ dependencies:
       - !ruby/object:Gem::Version
         version: 0.3.1
 description: |
-  The same pure-Ruby wrapper as the enola gem over another channel: the
-  builds cut from a fork of enola, each release naming what differs. This
+  The binary this gem fetches is not an enola-labs release. It is a build
+  cut from https://github.com/misabegovic/enola, a fork of enola, whose
+  release notes name what differs from upstream release by release; this
   gem drives channel release 0.4.4.2, built on enola
-  0.4.4. `munola init` writes the recipe catalogue the
+  0.4.4. Everything else is the enola gem's wrapper,
+  unchanged: fetched on first use, verified against the checksums the
+  release publishes, cached per user, every command and exit code
+  forwarded. Use the enola gem to run stock upstream instead.
+
+  What the fork adds: `munola init` writes the recipe catalogue the
   enola-guides gem carries (Ember, data ownership, API boundaries,
-  background work, a tenant foreign key) into the project and binds the
-  recipes its tree justifies, and turns both Ruby providers on by default. The Rails generator lives in munola-rb. Offered
-  upstream where it fits; no binary here, nothing compiled.
+  background work, a tenant foreign key) into the project, binds the
+  recipes its tree justifies, and turns both Ruby providers on by default.
+  The Rails generator lives in munola-rb. Offered upstream where it fits;
+  no binary here, nothing compiled.
 email:
 - m.isabegovic@hotmail.com
 executables:
@@ -104,6 +111,6 @@ requirements: []
 rubygems_version: 3.5.22
 signing_key:
 specification_version: 4
-summary: 'One person''s taste on top of enola: a channel of its own and a recipe catalogue
-  bound by what the tree shows.'
+summary: 'Runs a fork build of enola, not the enola-labs release: a channel of its
+  own and a recipe catalogue bound by what the tree shows.'
 test_files: []