enola 0.5.2 → 0.5.4

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 0f5c39f1dcc7577ecde43a125b51c74b640ec8f10ce6d38e4008bec02d7e8df6
-  data.tar.gz: 3a56415c6823950a6e115dbbe1b282f564e609211ee65609ef39b7e5daa35f15
+  metadata.gz: 8765810bf2e4d590bbbba5be8636b967a32850c114c77062f122f352178f2efd
+  data.tar.gz: 3e5b6fcc384b5a4744be1f691fb219968f407b303e2b3220b2333e0c1e59840f
 SHA512:
-  metadata.gz: 9f2727a63a05b9aee2c24023014d7363c1b2fac11e4ad4cea85473d14bb4534fe769d5ff6e6c3ee6b71fd2a853cadd0d2dc67b72772d5188c2a63b7e05a5c033
-  data.tar.gz: 98734b4d06a0867d8808f023e59276d6c1b8e9dec27703078c5ae98f8dd02a2bd2add19606f42d4442f914b21818839af4bb5717448af5180aafd5ebb88453ca
+  metadata.gz: 59ee62e4dce004b6828775875e6c68ed8821744ff47e69181a2d0dbdc0040d3ef46f0466b12b9bbd67fbffe7dc851de9bb3fae388f3a33c9680a51d1be630193
+  data.tar.gz: 327a5ccd99c2842900aaedf773e2d550a756447ffd8990dc883b46c6687922cdb02d45cbf709614d80658a6b957ad75f31dc41924684e75a6851f6a3a696994f

data/CHANGELOG.md

@@ -1,3 +1,49 @@
+## enola 0.5.4 and enola-rb 0.5.4 (2026-08-30)
+
+The gems drive upstream enola 0.4.10. Between 0.4.6 and here upstream took the
+exclusion filter (#255, in 0.4.7), rescored the layers explainer per language
+cohort (0.4.7), began reading package manifests as dependency facts with a
+declared-purpose diff (0.4.8), gave the dashboard its own command (0.4.9), and
+documented the snapshot artifacts as a versioned contract with fact identity
+(0.4.10). The vendored Prism provider script and the Rubydex engine pin are
+byte-identical across the span, so nothing re-vendors; the wrappers move by
+the release they name.
+
+## munola 0.6.1 (2026-08-24)
+
+munola drives channel release `0.4.6.1`, cut from the promoted current at
+upstream enola 0.4.6. The prefix walk fix is in the binary this gem fetches,
+so the expiry the 0.6.0 note named is met and Rubydex is on by default again.
+The channel still carries the exclusion filter, which upstream merged an hour
+after 0.4.6 was published, so an excluded document is skipped before its
+definitions are read: 440 seconds to 193 on a Rails monolith, facts identical.
+
+The 0.6.0 note said munola waits on Prism alone. On the Rails install path it
+did not. `munola init` reuses enola-rb's installer, which writes
+`mcp-arch.yaml` first, and munola's own writer yields to a file that already
+exists, so the config every Rails project got was the enola gem's, with both
+providers on, against a channel binary built before the fix. Two things follow.
+The config and the binary now agree, which is what closes it. And munola's
+writer has a test that reads munola's writer, rather than one that reads the
+file enola-rb wrote and reports on munola.
+
+## 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

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/enola/config.rb

@@ -20,11 +20,9 @@ module Enola
 
     def self.render(ruby: Providers.ruby)
       <<~YAML
-        # Written by the enola gem; edit freely. Prism is on by default and runs
-        # under the Ruby that runs the gem. Rubydex is left off: the release this
-        # gem drives has a walk that can fail to return on a tree with vendored
-        # gems, fixed but not yet in a published enola. Uncomment it to run it
-        # anyway, and expect a snapshot that may not finish.
+        # Written by the enola gem; edit freely. Both providers are on: Prism runs
+        # under the Ruby that runs the gem, Rubydex is built into the binary and
+        # fetched once. Remove one to leave it out of the graph.
         repo: .
         repos:
           - .
@@ -34,8 +32,8 @@ module Enola
           - name: prism
             command: [#{ruby.inspect}, #{Providers.prism_script.inspect}]
             expected_version: "#{Providers.prism_version || '0.1.0'}"
-        # - name: rubydex
-        #   expected_version: "#{Providers::RUBYDEX_EXPECTED_VERSION}"
+          - name: rubydex
+            expected_version: "#{Providers::RUBYDEX_EXPECTED_VERSION}"
       YAML
     end
   end

data/lib/enola/version.rb

@@ -3,6 +3,6 @@
 module Enola
   # The gem versions itself. UPSTREAM_VERSION names the enola release it
   # fetches and drives.
-  UPSTREAM_VERSION = "0.4.4"
-  VERSION = "0.5.2"
+  UPSTREAM_VERSION = "0.4.10"
+  VERSION = "0.5.4"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: enola
 version: !ruby/object:Gem::Version
-  version: 0.5.2
+  version: 0.5.4
 platform: ruby
 authors:
 - Muhamed Isabegovic
 autorequire:
 bindir: exe
 cert_chain: []
-date: 2026-08-23 00:00:00.000000000 Z
+date: 2026-08-30 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: prism
@@ -27,7 +27,7 @@ dependencies:
 description: |
   A pure-Ruby wrapper around enola, the architecture-graph tool by enola-labs.
   The gem versions itself; the enola release it drives is named in its
-  UPSTREAM_VERSION, 0.4.4 here. The binary is not in the
+  UPSTREAM_VERSION, 0.4.10 here. The binary is not in the
   gem: the first command that needs it downloads the release for your
   platform, verifies it against the checksum the release publishes, and keeps
   it in a per-user cache. Every command and exit code is forwarded unchanged.
@@ -81,5 +81,5 @@ rubygems_version: 3.5.22
 signing_key:
 specification_version: 4
 summary: 'Runs the released enola from Ruby: fetched on first use, verified, cached.
-  This release drives enola 0.4.4.'
+  This release drives enola 0.4.10.'
 test_files: []