enola-rb 0.4.4 → 0.4.4.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 8187cf70720cf851a17def67c9ca82f66766dbf0437779037143298f7b219aec
-  data.tar.gz: da2463ad162461bfcf32015aa7074ef6e5c534e50c3533c995077c53fd1298ab
+  metadata.gz: 658b73fa861835a5a16543d8a01df73071731416f3bcb72d9486a2a946de6e07
+  data.tar.gz: 484d12481e8e6ee1463e5591dbfac60dbd88e2d696203e6eedf9ca7bf7865b59
 SHA512:
-  metadata.gz: bd244d2988659a63032fca993b743a12897cc18eaf722e826c4f1f4e63620d60932f0ba481ff095260f0cd9f60bd669d5add4dd4c0b16d3b114fe58b5503456b
-  data.tar.gz: 3faf0965d57a14e8e853a444d9481fd90ae14732006ffc73eb0e2b1da9b14c4740f5af3728bceecb6ff08e370c3b9f335685004976737eacd609fb2c940397bc
+  metadata.gz: b869c59958778ed2d83e36a9736de7ceefda2b5eea4fcf5314b39a61ebab3f1d3845dc79e94a795d05246e21bfbfa63f1d7b900a8a7a7d5f800cc759f6128da3
+  data.tar.gz: c0800f82499e1202b7deffbdf2da7993b14df0d5ac19bd4646655f1ef0b0253441b31d0df857bba504b66c2d69fabb8fed3cd521350cd3f5e8d68ca746d49c24

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_rb/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module EnolaRb
-  VERSION = "0.4.4"
+  VERSION = "0.4.4.1"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: enola-rb
 version: !ruby/object:Gem::Version
-  version: 0.4.4
+  version: 0.4.4.1
 platform: ruby
 authors:
 - Muhamed Isabegovic
@@ -16,14 +16,14 @@ dependencies:
     requirements:
     - - '='
       - !ruby/object:Gem::Version
-        version: 0.4.4
+        version: 0.4.4.1
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - '='
       - !ruby/object:Gem::Version
-        version: 0.4.4
+        version: 0.4.4.1
 - !ruby/object:Gem::Dependency
   name: enola-guides
   requirement: !ruby/object:Gem::Requirement
@@ -61,7 +61,6 @@ files:
 - lib/enola_rb/tasks.rake
 - lib/enola_rb/version.rb
 - lib/generators/enola/install/install_generator.rb
-- lib/generators/munola/install/install_generator.rb
 homepage: https://github.com/misabegovic/enola-rb
 licenses:
 - Apache-2.0

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

@@ -1,19 +0,0 @@
-# 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