Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

"uninitialized constant Haml::Options" error while launching Middleman server on a fresh install #2569

Closed
teemutammela opened this issue Sep 21, 2022 · 15 comments
Closed

"uninitialized constant Haml::Options" error while launching Middleman server on a fresh install #2569

teemutammela opened this issue Sep 21, 2022 · 15 comments

Comments

@teemutammela
Copy link

I tried creating a fresh new Middleman project and launching the server.

$ gem install middleman
$ mkdir project
$ middleman init
$ middleman server

Command middleman server fails to launch giving the following error message:

/Users/username/.rvm/gems/ruby-3.1.2/gems/middleman-core-4.4.2/lib/middleman-core/renderers/haml.rb:49:in `initialize': uninitialized constant Haml::Options (NameError)

::Haml::Options.defaults[:context] = nil

I'm also getting the same error message this way.

$ gem install middleman
$ middleman init project

Additional information

  • Ruby version: 3.1.2 installed via RVM
  • Middleman version: 4.2.2
  • OS version: macOS 12.5
zofrex added a commit to zofrex/middleman that referenced this issue Sep 21, 2022
@zofrex
Lock haml to < 6.0
d102f7f 
6.0 introduces breaking changes (see middleman#2569)
zofrex added a commit to zofrex/middleman that referenced this issue Sep 21, 2022
@zofrex
Lock haml to < 6.0
5f78d94 
6.0 introduces breaking changes (see middleman#2569)
@zofrex zofrex mentioned this issue Sep 21, 2022
Merged
@zofrex
Copy link
Contributor

zofrex commented Sep 21, 2022

As a temporary workaround you can fix this in any project using a Gemfile by limiting the version of haml in your Gemfile, for example:

source "https://rubygems.org"

gem 'middleman', '~> 4.2'
gem 'middleman-autoprefixer'

# Temporary fix for https://github.com/middleman/middleman/issues/2569
gem 'haml', '~> 5.0'

@teemutammela
Copy link
Author

Thanks, that temporary solution fixed the problem for now. Any ETA for a permanent fix?

tdreyno pushed a commit that referenced this issue Sep 21, 2022
@zofrex
Lock haml to < 6.0 (#2570)
08c5061 
6.0 introduces breaking changes (see #2569)
@mickotronic
Copy link

I'm seeing the same problem. I can lock the haml gem inside an existing project's Gemfile, however that doesn't solve the issue that middleman init installs haml 6.0, and then errors with the error described in the issue title and description.

After the middleman init fails, I remove haml 6.0 with gem uninstall, then the init works. However, during the creation of the new site, it installs haml 6.0 again. I could then lock the new project's haml inside the Gemfile, but it seems like init is installing haml 6.0.

@levinotik
Copy link

Same problem for me. Brand new project with middleman init Result is:

/Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/renderers/haml.rb:49:in `initialize': uninitialized constant Haml::Options (NameError)

        ::Haml::Options.defaults[:context] = nil
              ^^^^^^^^^
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/extension_manager.rb:66:in `new'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/extension_manager.rb:66:in `activate'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/extensions.rb:120:in `block in auto_activate'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/3.1.0/set.rb:511:in `each_key'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/3.1.0/set.rb:511:in `each'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/extensions.rb:117:in `auto_activate'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/extension_manager.rb:28:in `auto_activate'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/extension_manager.rb:20:in `block (2 levels) in initialize'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/callback_manager.rb:57:in `instance_exec'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/callback_manager.rb:57:in `block in execute'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/hamster-3.0.0/lib/hamster/vector.rb:1316:in `each'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/hamster-3.0.0/lib/hamster/vector.rb:1316:in `traverse_depth_first'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/hamster-3.0.0/lib/hamster/vector.rb:431:in `each'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/callback_manager.rb:57:in `execute'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/contracts-0.13.0/lib/contracts/method_reference.rb:43:in `send_to'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/contracts-0.13.0/lib/contracts/call_with.rb:76:in `call_with'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/contracts-0.13.0/lib/contracts/method_handler.rb:138:in `block in redefine_method'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/callback_manager.rb:28:in `block in install_methods!'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/application.rb:280:in `initialize'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-cli-4.4.2/bin/middleman:49:in `new'
	from /Users/levinotik/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-cli-4.4.2/bin/middleman:49:in `<top (required)>'
	from /Users/levinotik/.rbenv/versions/3.1.2/bin/middleman:25:in `load'
	from /Users/levinotik/.rbenv/versions/3.1.2/bin/middleman:25:in `<main>'

@ntsim
Copy link

ntsim commented Sep 26, 2022

Same as above - middleman init is throwing the same error for me

tim-vandecasteele added a commit to tim-vandecasteele/lauranne-paulissen that referenced this issue Sep 27, 2022
@tim-vandecasteele
Fix issue with haml version
4f371bc 
middleman/middleman#2569
juno pushed a commit to qnyp/qnyp-company that referenced this issue Oct 1, 2022
Revert "chore(deps): Bump haml from 5.2.2 to 6.0.3"
938d390 
This reverts commit 21d1e10.

Because of incompatibility with middleman.
middleman/middleman#2569
@michaelrichey
Copy link

I ran into this issue today (2022-10-12) on a fresh middleman install.

I started with Ruby version 3.1.2 and middleman init could not complete, and I got the haml error described.

Then I dropped down to Ruby version 3.0.3 and middleman init completed. Then bundle exec middleman server gave me the haml error.

The workaround provided here solved the issue for me, but recent commits don't seem to have solved the issue, at least not for me.

@foxacid
Copy link

foxacid commented Oct 17, 2022

Same issue.

  • Ruby 3.1.2 installed via chruby
  • Middleman 4.4.2
  • macOS 12.6 (M1)

@akhil-damarla
Copy link

I'm still having the same issue even with the fix mentioned above running into this error when I run middleman init:
/Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/renderers/haml.rb:49:in `initialize': uninitialized constant Haml::Options (NameError)

    ::Haml::Options.defaults[:context] = nil
          ^^^^^^^^^
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/extension_manager.rb:66:in `new'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/extension_manager.rb:66:in `activate'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/extensions.rb:120:in `block in auto_activate'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/3.1.0/set.rb:511:in `each_key'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/3.1.0/set.rb:511:in `each'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/extensions.rb:117:in `auto_activate'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/extension_manager.rb:28:in `auto_activate'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/extension_manager.rb:20:in `block (2 levels) in initialize'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/callback_manager.rb:57:in `instance_exec'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/callback_manager.rb:57:in `block in execute'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/hamster-3.0.0/lib/hamster/vector.rb:1316:in `each'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/hamster-3.0.0/lib/hamster/vector.rb:1316:in `traverse_depth_first'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/hamster-3.0.0/lib/hamster/vector.rb:431:in `each'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/callback_manager.rb:57:in `execute'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/contracts-0.13.0/lib/contracts/method_reference.rb:43:in `send_to'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/contracts-0.13.0/lib/contracts/call_with.rb:76:in `call_with'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/contracts-0.13.0/lib/contracts/method_handler.rb:138:in `block in redefine_method'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/callback_manager.rb:28:in `block in install_methods!'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-core-4.4.2/lib/middleman-core/application.rb:280:in `initialize'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-cli-4.4.2/bin/middleman:49:in `new'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/middleman-cli-4.4.2/bin/middleman:49:in `<top (required)>'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/bin/middleman:25:in `load'
    from /Users/akhildamarla/.rbenv/versions/3.1.2/bin/middleman:25:in `<main>'

@markets
Copy link
Member

markets commented Oct 24, 2022 •
edited

Hello everyone 👋🏼 The fix was already merged (in both branches, 4.x and 5.x), but still not released, see:

In the meantime, you can point the gem to GitHub 4.x branch:

gem 'middleman', github: 'middleman', branch: '4.x'

Or if you are already using on 5.x:

gem 'middleman', github: 'middleman', branch: 'master'

betesh added a commit to betesh/hebrewCalendar.js that referenced this issue Nov 6, 2022
@betesh
Upgrade bundle, using middleman from github to work around middleman/…
6dbe820 
…middleman#2569
@k0kubun
Copy link
Contributor

k0kubun commented Nov 9, 2022

see also: #2588

@tdreyno
Copy link
Member

tdreyno commented Nov 9, 2022

Published as v4.4.3 https://rubygems.org/gems/middleman/versions/4.4.3

@tdreyno tdreyno closed this as completed Nov 9, 2022
@k0kubun
Copy link
Contributor

k0kubun commented Nov 10, 2022

Could we possibly release master as 5.0.0.rc2 as a first Haml 6-compatible version?

@markets
Copy link
Member

markets commented Nov 10, 2022 •
edited

hi @k0kubun 👋🏼

I had a conversation yesterday with @tdreyno, about this weird situation between v4 and v5.

We came up with some ideas. Maybe we should do the following?

  • release current master as v5.0.0.rc2
  • move current master to a new v5 branch
  • move v4 to master again

@k0kubun
Copy link
Contributor

k0kubun commented Nov 11, 2022

Sounds good!

@k0kubun
Copy link
Contributor

k0kubun commented Nov 11, 2022 •
edited

I also prepared a backport to the current 4.x branch #2590. Please consider merging (and releasing) it before or after the rename.

@markets markets mentioned this issue Dec 20, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests