Hi! Thanks for the recent v1.3.1 and v1.3.2 releases. I tried both on a clean Discourse install and both fail at bundle exec rake db:migrate during ./launcher rebuild app. Sharing details in case it helps.
Environment
Fresh Discourse install (./discourse-setup, no prior state)
Discourse base image: discourse/base:2.0.20260209-1300
Ruby 3.4.7
Ubuntu 24.04 host
Only plugins enabled: docker_manager + discourse-siwe-auth
v1.3.2 failure
gem install rbsecp256k1 -v 6.0.0 -i .../discourse-siwe-auth/gems/3.4.7
--no-document --ignore-dependencies --no-user-install
ERROR: Failed to build gem native extension.
extconf.rb:3:in '
'
cannot load such file -- mini_portile2 (LoadError)
Root cause: Discourse's plugin install path uses --ignore-dependencies, so removing the explicit mini_portile2 pin in v1.3.2 means it never gets installed. rbsecp256k1's extconf.rb then can't require 'mini_portile2'.
v1.3.1 failure
gem install rubyzip -v 2.4.1 ...
Gem::LoadError: can't activate rubyzip-2.4.1, already activated rubyzip-3.3.0
/var/www/discourse/plugins/discourse-siwe-auth/plugin.rb:16
Root cause: the current Discourse base bundles rubyzip 3.3.0, not 3.2.2 as referenced in the v1.3.2 release notes. The gem 'rubyzip', '2.4.1' line in v1.3.1's plugin.rb triggers a version conflict at boot.
Workaround I'm using
v1.3.2 + a before_code hook in app.yml that pre-installs the install-time-only deps system-wide:
hooks:
before_code:
- exec:
cmd:
- gem install mini_portile2 -v 2.8.9 --no-document
- gem install pkg-config -v 1.5.0 --no-document
Suggested fix
Re-add mini_portile2 and pkg-config as explicit gem declarations in plugin.rb (they're install-time only, no runtime overhead). Keep rubyzip removed — your v1.3.2 reasoning on rubyzip is correct, the base provides it.
Thanks again for the active maintenance!
When I ask what might be causing the divergence in out testing result this is what came up:
Three plausible reasons, all of which point to the same root cause: he's not testing against the same install path you are.
Older Discourse base image. His v1.3.2 release notes explicitly say "discourse/base already bundles rubyzip 3.2.2." But the current base image (2.0.20260209-1300, dated 9 Feb 2026) ships rubyzip 3.3.0. Between his test and your install, Discourse bumped rubyzip a minor version. v1.3.1's pin to 2.4.1 no longer co-exists with the active 3.3.0 — that exact conflict didn't exist when he last tested.
Dev install path vs production launcher path. Discourse's ./launcher rebuild app runs plugin gem installs with gem install --ignore-dependencies. That's the line you can see in your log:
gem install rbsecp256k1 ... --ignore-dependencies --no-user-install
The --ignore-dependencies flag tells RubyGems "don't pull transitive deps." So mini_portile2 (a transitive dep of rbsecp256k1) doesn't get installed. But if he tests locally with bundle install or bin/rails server, bundler resolves the full dependency graph and pulls mini_portile2 automatically. He never sees the failure because his test runner doesn't use the same flag.
Pre-existing gem cache. His dev machine almost certainly already has mini_portile2 installed system-wide (it's a transitive dep of nokogiri, sqlite3, and a dozen other common gems). When extconf.rb runs require 'mini_portile2', it finds it. On a fresh Discourse container, the system Ruby has nothing extra installed → require fails.
The bottom line: his confidence is real for his test environment but the test environment doesn't match production. This is a common blind spot for plugin maintainers.
Hi! Thanks for the recent v1.3.1 and v1.3.2 releases. I tried both on a clean Discourse install and both fail at bundle exec rake db:migrate during ./launcher rebuild app. Sharing details in case it helps.
Environment
'Fresh Discourse install (./discourse-setup, no prior state)
Discourse base image: discourse/base:2.0.20260209-1300
Ruby 3.4.7
Ubuntu 24.04 host
Only plugins enabled: docker_manager + discourse-siwe-auth
v1.3.2 failure
gem install rbsecp256k1 -v 6.0.0 -i .../discourse-siwe-auth/gems/3.4.7
--no-document --ignore-dependencies --no-user-install
ERROR: Failed to build gem native extension.
extconf.rb:3:in '
cannot load such file -- mini_portile2 (LoadError)
Root cause: Discourse's plugin install path uses --ignore-dependencies, so removing the explicit mini_portile2 pin in v1.3.2 means it never gets installed. rbsecp256k1's extconf.rb then can't require 'mini_portile2'.
v1.3.1 failure
gem install rubyzip -v 2.4.1 ...
Gem::LoadError: can't activate rubyzip-2.4.1, already activated rubyzip-3.3.0
/var/www/discourse/plugins/discourse-siwe-auth/plugin.rb:16
Root cause: the current Discourse base bundles rubyzip 3.3.0, not 3.2.2 as referenced in the v1.3.2 release notes. The gem 'rubyzip', '2.4.1' line in v1.3.1's plugin.rb triggers a version conflict at boot.
Workaround I'm using
v1.3.2 + a before_code hook in app.yml that pre-installs the install-time-only deps system-wide:
hooks:
before_code:
- exec:
cmd:
- gem install mini_portile2 -v 2.8.9 --no-document
- gem install pkg-config -v 1.5.0 --no-document
Suggested fix
Re-add mini_portile2 and pkg-config as explicit gem declarations in plugin.rb (they're install-time only, no runtime overhead). Keep rubyzip removed — your v1.3.2 reasoning on rubyzip is correct, the base provides it.
Thanks again for the active maintenance!
When I ask what might be causing the divergence in out testing result this is what came up:
Three plausible reasons, all of which point to the same root cause: he's not testing against the same install path you are.
Older Discourse base image. His v1.3.2 release notes explicitly say "discourse/base already bundles rubyzip 3.2.2." But the current base image (2.0.20260209-1300, dated 9 Feb 2026) ships rubyzip 3.3.0. Between his test and your install, Discourse bumped rubyzip a minor version. v1.3.1's pin to 2.4.1 no longer co-exists with the active 3.3.0 — that exact conflict didn't exist when he last tested.
Dev install path vs production launcher path. Discourse's ./launcher rebuild app runs plugin gem installs with gem install --ignore-dependencies. That's the line you can see in your log:
gem install rbsecp256k1 ... --ignore-dependencies --no-user-install
The --ignore-dependencies flag tells RubyGems "don't pull transitive deps." So mini_portile2 (a transitive dep of rbsecp256k1) doesn't get installed. But if he tests locally with bundle install or bin/rails server, bundler resolves the full dependency graph and pulls mini_portile2 automatically. He never sees the failure because his test runner doesn't use the same flag.
Pre-existing gem cache. His dev machine almost certainly already has mini_portile2 installed system-wide (it's a transitive dep of nokogiri, sqlite3, and a dozen other common gems). When extconf.rb runs require 'mini_portile2', it finds it. On a fresh Discourse container, the system Ruby has nothing extra installed → require fails.
The bottom line: his confidence is real for his test environment but the test environment doesn't match production. This is a common blind spot for plugin maintainers.