enola 0.4.4 → 0.5.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: b1c9e53fd33fd57e5764c1e4e3e2e6b71ac74145a5fd15aeac99d0efe896e21e
-  data.tar.gz: ab03a293ad4cb939351e4dcbed5680c84959e8797834bde3db9e45eb6c500746
+  metadata.gz: 689fed2c591f5809d780118557d16abb71dd2c16ae81e71382fbeee1cb70001e
+  data.tar.gz: c7c4671e4d4c153f8f0f6db9f9395a6670681a1006581c5faecf2b196170cc30
 SHA512:
-  metadata.gz: 252640692ed6d525918737d1ff1d74c3849321f3eac480fe1455aa92823eafba7c4555924f71ac08830c104732af687eebc17a92192b32edc446d5516f154b85
-  data.tar.gz: 4018811a6cdd5ef38fc5e8703444fba327f761135214ced01f8847f22487edf32dfe3c0c204a5018c250ead313484ae1350059f6e7834a8acc97661a668bd798
+  metadata.gz: b4a72e0931b1f110f482062fa8e2627f59adfac7add1592ea1c8ef22e5bc4f6f7fc5c4ae851cf7534c50997ec8fc3cd2928e3e84a0e3bc841f9f22ee87933d85
+  data.tar.gz: 7f5cd2dc8f9b69897c095c54e95d4c9d58913607de47ca71789fa3eb8d419811d5d2c5393cc6abed7630e2f35314b6c76b61836beff63fa012761eaa0f27c4e7

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/LICENSE

@@ -187,7 +187,7 @@ APPENDIX: How to apply the Apache License to your work.
   same "printed page" as the copyright notice for easier
   identification within third-party archives.
 
-Copyright (c) 2026 Dejan Menges
+Copyright (c) 2026 Muhamed Isabegovic
 
 Licensed under the Apache License, Version 2.0 (the "License");
 you may not use this file except in compliance with the License.

data/README.md

@@ -1,13 +1,19 @@
 # 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
-drives: `enola 0.4.4` runs enola-labs' v0.4.4.
+The wrapper of the released enola. The gem versions itself; the release it
+drives is `Enola::UPSTREAM_VERSION`, v0.4.4 as of `enola 0.5.0`, and every
+gemspec summary names it.
 
 ```ruby
 gem "enola"
@@ -39,7 +45,7 @@ This gem is not an enola-labs release; it runs theirs.
 
 ## `enola-rb`
 
-The Rails layer over `enola`. It depends on `enola` at the same version and on
+The Rails layer over `enola`. It depends on `enola` at the same minor and on
 [enola-guides](https://github.com/misabegovic/enola-guides), and adds nothing
 to the binary's surface.
 
@@ -68,18 +74,17 @@ remedy.
 
 One person's taste on top of enola: the same wrapper over another channel,
 the builds cut from [a fork of enola](https://github.com/misabegovic/enola),
-versioned as the upstream they are built on plus a fourth segment
-(`0.4.4.1` drives a build on v0.4.4), each release naming what differs from
-that upstream. It is offered upstream where it fits and is not positioned
-against it. What it adds is the channel and the catalogue.
+each release naming what differs from that upstream. The gem versions itself;
+the channel release it fetches is `Munola::CHANNEL_VERSION`, which carries the
+upstream it is built on plus a segment of its own (`0.4.4.2` on v0.4.4). It is
+offered upstream where it fits and is not positioned against it. What it adds is the channel and the catalogue.
 
 ```ruby
 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
 ```
 
@@ -95,9 +100,31 @@ inflection table; it writes `mcp-arch.yaml` with both Ruby providers on by
 default, Prism through the script the `enola` gem carries and Rubydex built
 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.
+version, the channel release and upstream it is built on, and which binary
+answered.
+
+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 the same
+minor 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 the same minor 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 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 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 gem versions itself. UPSTREAM_VERSION names the enola release it
+  # fetches and drives.
+  UPSTREAM_VERSION = "0.4.4"
+  VERSION = "0.5.0"
 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.5.0
 platform: ruby
 authors:
 - Muhamed Isabegovic
@@ -26,8 +26,9 @@ dependencies:
         version: '1.3'
 description: |
   A pure-Ruby wrapper around enola, the architecture-graph tool by enola-labs.
-  The gem's version is the upstream release it drives. The binary is not in
-  the gem: the first command that needs it downloads the release for your
+  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
+  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.
   This gem is not an enola-labs release.
@@ -79,6 +80,6 @@ requirements: []
 rubygems_version: 3.5.22
 signing_key:
 specification_version: 4
-summary: 'Runs the released enola from Ruby: fetched on first use, verified, pinned
-  to this gem''s version.'
+summary: 'Runs the released enola from Ruby: fetched on first use, verified, cached.
+  This release drives enola 0.4.4.'
 test_files: []