enola 0.4.4 → 0.4.4.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: b1c9e53fd33fd57e5764c1e4e3e2e6b71ac74145a5fd15aeac99d0efe896e21e
-  data.tar.gz: ab03a293ad4cb939351e4dcbed5680c84959e8797834bde3db9e45eb6c500746
+  metadata.gz: 84ee668ecfaed2e6d8ebc55fe5054e1635300502f762887f2d7b96660beb908f
+  data.tar.gz: 2905c89cad26afb7f6226515c7b3620ed6e089c16ff5886398f4043deda50360
 SHA512:
-  metadata.gz: 252640692ed6d525918737d1ff1d74c3849321f3eac480fe1455aa92823eafba7c4555924f71ac08830c104732af687eebc17a92192b32edc446d5516f154b85
-  data.tar.gz: 4018811a6cdd5ef38fc5e8703444fba327f761135214ced01f8847f22487edf32dfe3c0c204a5018c250ead313484ae1350059f6e7834a8acc97661a668bd798
+  metadata.gz: e8b8a19a54c9f13be8b2dd6a1d62b5cb999d14a7ff959f0771ca25cfc63b6fac3822bc31ccd676cc44c60e4106401c626f9fc1e7b2802a68d3f5f68a0c23c322
+  data.tar.gz: 42a9119e1b7d33d1a20b3e3d9f7a79f2c8199de3599365f6d13674db19a968aba0a749180014b061bb413940a17ae8212ebf63181ee40302acdcae20952c1bb5

data/CHANGELOG.md

@@ -1,3 +1,34 @@
+## 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
+channel after it took eight changes measured against a Ruby architecture
+linter, so the gem's version moves with the release it fetches. The Rails
+layer is its own gem, `munola-rb`, the way `enola-rb` is for the upstream
+channel; `require "munola"` loads no Rails. A catalogue recipe the binary
+already binds is no longer bound a second time.
+
+## enola 0.4.4.1 and enola-rb 0.4.4.1 (2026-08-23)
+
+Wrapper fixes on the same upstream release. A test that set the channel put
+back upstream rather than what it found, so on some orderings a channel gem's
+own installation read as upstream. The Rails layer packaged its generator
+through a glob wide enough to take another channel's; it now packages its own.
+Both gems still drive upstream v0.4.4.
+
+## munola-rb 0.4.4.1 (2026-08-23)
+
+The Rails layer over munola, what enola-rb is to enola: `rails generate
+munola:install [--tenant-column COLUMN]` writes the starter laws, the
+bindings the binary's own init picks and the munola catalogue, and the
+enola:init, enola:snapshot and enola:check tasks drive munola's binary
+because munola installs its own resolver. The generator and the railtie
+move here out of the munola gem, so `require "munola"` loads no Rails and a
+project that only drives the binary carries no Rails machinery. The recipe
+catalogue, the detection and the tenant-column argument stay munola's.
+
+`Enola.resolver_factory` is readable as well as writable, so whoever
+replaces it can put back what was installed rather than what it assumed.
+
 ## munola 0.4.4.1 (2026-08-23)
 
 The wrapper over the munola channel, first release with an implementation.

data/README.md

@@ -1,9 +1,14 @@
 # enola-rb
 
-Three pure-Ruby gems, one repository, for running
+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.
+
 ## `enola`
 
 The wrapper of the released enola. Its version is the upstream release it
@@ -78,8 +83,7 @@ gem "munola"
 ```
 
 ```sh
-bin/rails generate munola:install --tenant-column company_id
-bundle exec munola init .
+bundle exec munola init . --tenant-column company_id
 bundle exec munola --version
 ```
 
@@ -97,7 +101,28 @@ into the binary, and fetches the Rubydex library, a failed fetch reported as a
 named skip. It never asks a question. `munola --version` names the munola
 version, the upstream it is built on and which binary answered.
 
-The first munola release is what makes the channel real; until it is cut,
-`MUNOLA_BINARY=/path/to/enola` names the binary to drive, and every command
-says so. `munola` depends on `enola` and `enola-rb` at its upstream version
-and on `enola-guides` 0.3.1 or later.
+The binary comes from the fork's releases the way `enola`'s comes from
+upstream's, fetched on first use and verified against the sha256 the release
+publishes; `MUNOLA_BINARY=/path/to/enola` names one to drive instead, and
+every command says which answered. `munola` depends on `enola` at its upstream
+version and on `enola-guides` 0.3.1 or later; requiring it loads no Rails.
+
+## `munola-rb`
+
+The Rails layer over `munola`, what `enola-rb` is to `enola`. It depends on
+both at their own versions and adds one generator.
+
+```ruby
+gem "munola-rb"
+```
+
+```sh
+bin/rails generate munola:install --tenant-column company_id
+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.

data/lib/enola/channel.rb

@@ -30,7 +30,7 @@ module Enola
   Channel::UPSTREAM = Channel.new(
     name: "upstream",
     release_base: "https://github.com/enola-labs/enola/releases/download",
-    version: VERSION,
+    version: UPSTREAM_VERSION,
     asset_prefix: "enola"
   ).freeze
 end

data/lib/enola/version.rb

@@ -1,5 +1,8 @@
 # frozen_string_literal: true
 
 module Enola
-  VERSION = "0.4.4"
+  # The release this wrapper drives. VERSION carries a patch segment for
+  # wrapper-only fixes, so what to fetch is stated separately.
+  UPSTREAM_VERSION = "0.4.4"
+  VERSION = "#{UPSTREAM_VERSION}.1"
 end

data/lib/enola.rb

@@ -14,10 +14,14 @@ require_relative "enola/cli"
 
 module Enola
   class << self
-    attr_writer :channel, :resolver_factory
+    attr_writer :channel
 
     # Another channel's gem installs its own resolver here, so every rake
     # task and wrapped command built on Runner drives that channel's binary.
+    # Readable as well as writable: whoever replaces it can put back what was
+    # installed rather than what it assumed.
+    attr_accessor :resolver_factory
+
     def resolver
       (@resolver_factory || -> { Resolver.new(channel: channel) }).call
     end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: enola
 version: !ruby/object:Gem::Version
-  version: 0.4.4
+  version: 0.4.4.1
 platform: ruby
 authors:
 - Muhamed Isabegovic