munola 0.5.1 → 0.6.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 1ab78c18a2c9958d0c634e2177f711100a0fb3d6238a792d821a5ae559a84ec3
-  data.tar.gz: 4fb06f8764e9678598ea2a202168009e6e105352f67f05209a0ee1fbe455fc2c
+  metadata.gz: 558cd383ea993d03a3a667a3287a7ae27db1f8a41642e63bce0727846a1af987
+  data.tar.gz: 5cd95dccec42025f8cea27b8b6aaa528f8a1f7e4b17ddb1be53541a12bf62268
 SHA512:
-  metadata.gz: 8e283df48b4b6f8de613a40e3898c1912568dceab40069fd5af52cfb02db3aa11fc38e79440252566e84a66a5a096aed3590caf07a7a88f34780cfadb4e4309c
-  data.tar.gz: 8d91d165e1fccfe346955d617fd6b0786764619fafa3b4acff654ec327e0f7ec06dabad8e9600daab7dabb5821593e9b1676ff0e8286a0feea9fa93ae8076849
+  metadata.gz: 2a47d2376487ef8e19cf22b5f66d00f32eb1ab8e7cab3750846ccc048a6739ec5cd7f6f4e7a527079a7c5ca3555baeb5d2ac7cf9000c2aa4ed772e225d30be0b
+  data.tar.gz: 51e549f4e966e6ad231f7618c2b9e7826a84fa0b2c8972c3fd35ff666128bfdf2d0f2b9fda657139b1548ac2ae9a2f76c138e75e8c178a9ebc95f9aa3a7c5ccb

data/CHANGELOG.md

@@ -1,3 +1,55 @@
+## enola 0.5.3, enola-rb 0.5.3 and munola 0.6.0 (2026-08-24)
+
+Both providers are on again. enola-labs shipped the prefix walk fix in 0.4.6,
+which is the release the enola and enola-rb gems now drive, so the config they
+write carries Prism and Rubydex as it did before the hang was found.
+
+munola waits. Its binary is a fork release cut before that fix, so it stays on
+Prism alone until the channel is re-cut, and its version file says which
+upstream it is built on rather than implying the newest.
+
+munola-rb is gone, and was never published. The railtie and generator move
+into munola, which is why munola is 0.6.0: one gem for one channel, since the
+split that makes sense for enola and enola-rb, letting a Rubyist take the
+binary wrapper without the Rails layer, does not describe anyone's use of
+munola. Requiring munola still loads no Rails; the generator registers when
+the application has already loaded it.
+
+## 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/README.md

@@ -4,10 +4,11 @@ Four pure-Ruby gems, one repository, for running
 [enola](https://github.com/enola-labs/enola), the architecture-graph tool,
 from Ruby. None of them carries a binary or compiles anything.
 
-Two channels, the same layering on both: `enola` wraps the released upstream
-binary and `enola-rb` adds the Rails layer on it; `munola` wraps the munola
-binary and `munola-rb` adds the Rails layer on that. The Rails code is written
-once, in `enola-rb`, and the munola gems add only what is munola's own.
+Two channels. `enola` wraps the released upstream binary and `enola-rb` adds
+the Rails layer on it, split so a Rubyist can take the wrapper without Rails.
+`munola` is one gem for its own channel, wrapper and Rails layer together,
+because nobody installs it to avoid Rails. The Rails code is written once, in
+`enola-rb`, and munola adds only what is munola's own.
 
 ## `enola`
 
@@ -109,14 +110,9 @@ publishes; `MUNOLA_BINARY=/path/to/enola` names one to drive instead, and
 every command says which answered. `munola` depends on `enola` at the same
 minor and on `enola-guides` 0.3.1 or later; requiring it loads no Rails.
 
-## `munola-rb`
+## munola under Rails
 
-The Rails layer over `munola`, what `enola-rb` is to `enola`. It depends on
-both at the same minor and adds one generator.
-
-```ruby
-gem "munola-rb"
-```
+munola carries its own generator, and the rake tasks are enola-rb's:
 
 ```sh
 bin/rails generate munola:install --tenant-column company_id
@@ -124,7 +120,8 @@ bin/rake enola:snapshot
 bin/rake enola:check
 ```
 
-The generator runs the same install `munola init` does. The rake tasks are
-enola-rb's and need no munola copy: `munola` installs its own resolver when it
-loads, so `enola:snapshot` and `enola:check` drive the munola binary in an app
-that has this gem, and the upstream binary in one that does not.
+The generator runs the same install `munola init` does. `munola` installs its
+own resolver when it loads, so `enola:snapshot` and `enola:check` drive the
+munola binary in an app that has this gem, and the upstream binary in one that
+does not. Requiring munola loads no Rails; the generator registers when the
+application has already loaded it.

data/lib/generators/munola/install/install_generator.rb

@@ -0,0 +1,19 @@
+# frozen_string_literal: true
+
+require "rails/generators"
+require "munola"
+
+module Munola
+  module Generators
+    class InstallGenerator < Rails::Generators::Base
+      desc "Writes enola/constraints/ and the munola recipe catalogue, binding what the tree shows a need for"
+      class_option :tenant_column, type: :string, default: nil, desc: "The column most tables carry; confirmed against db/schema.rb"
+
+      def install
+        Munola::Installer.new(destination_root, tenant_column: options[:tenant_column]).install.lines.each { |line| say line }
+      rescue Enola::Error => e
+        raise Thor::Error, "munola: #{e.message}"
+      end
+    end
+  end
+end

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/railtie.rb

@@ -0,0 +1,10 @@
+# frozen_string_literal: true
+
+module Munola
+  # The enola:* tasks come from the enola-rb railtie and drive whatever channel
+  # is installed; requiring munola installs its resolver, so under this gem
+  # they run the munola binary. Only the generator is munola's own.
+  class Railtie < Rails::Railtie
+    generators { require_relative "../generators/munola/install/install_generator" }
+  end
+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.1"
+  VERSION = "0.6.0"
 end

data/lib/munola.rb

@@ -8,6 +8,10 @@ require_relative "munola/detector"
 require_relative "munola/providers_config"
 require_relative "munola/installer"
 require_relative "munola/cli"
+# munola is a wrapper first. enola-rb requires rails because it is the Rails
+# layer; munola only registers its generator when the application has already
+# loaded Rails, so driving the binary alone costs nothing.
+require_relative "munola/railtie" if defined?(Rails::Railtie)
 
 Enola.channel = Munola::CHANNEL
 Enola.resolver_factory = -> { Munola::Resolver.new(channel: Munola::CHANNEL) }

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: munola
 version: !ruby/object:Gem::Version
-  version: 0.5.1
+  version: 0.6.0
 platform: ruby
 authors:
 - Muhamed Isabegovic
 autorequire:
 bindir: exe
 cert_chain: []
-date: 2026-08-23 00:00:00.000000000 Z
+date: 2026-08-24 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: enola
@@ -16,28 +16,28 @@ dependencies:
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 0.5.0
+        version: 0.5.3
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 0.5.0
+        version: 0.5.3
 - !ruby/object:Gem::Dependency
   name: enola-rb
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 0.5.0
+        version: 0.5.3
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 0.5.0
+        version: 0.5.3
 - !ruby/object:Gem::Dependency
   name: enola-guides
   requirement: !ruby/object:Gem::Requirement
@@ -66,7 +66,7 @@ description: |
   enola-guides gem carries (Ember, data ownership, API boundaries,
   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;
+  Under Rails it adds `rails generate munola:install`; the enola:* rake tasks come from enola-rb and drive munola's binary. Offered upstream where it fits;
   no binary here, nothing compiled.
 email:
 - m.isabegovic@hotmail.com
@@ -79,6 +79,7 @@ files:
 - LICENSE
 - README.md
 - exe/munola
+- lib/generators/munola/install/install_generator.rb
 - lib/munola.rb
 - lib/munola/catalogue.rb
 - lib/munola/channel.rb
@@ -86,6 +87,7 @@ files:
 - lib/munola/detector.rb
 - lib/munola/installer.rb
 - lib/munola/providers_config.rb
+- lib/munola/railtie.rb
 - lib/munola/version.rb
 homepage: https://github.com/misabegovic/enola-rb
 licenses: