k0kubun / hamlit

High Performance Haml Implementation
https://rubygems.org/gems/hamlit
Other
980 stars 60 forks source link

Get Error: cannot load such file -- temple/static_analyzer (LoadError) #131

Closed wimrijnders closed 5 years ago

wimrijnders commented 5 years ago

Hi there, I'm installing my web server on a squeaky clean Debian distro. In the process, I decided upon replacing Haml with Hamlit.

On generation, I get an error, with a traceback ending in:

...
4: from /home/wim/.rvm/gems/ruby-2.5.1-latest/gems/hamlit-2.9.1/lib/hamlit/compiler.rb:59:in `block in compile_children'
3: from /home/wim/.rvm/gems/ruby-2.5.1-latest/gems/hamlit-2.9.1/lib/hamlit/compiler.rb:46:in `compile'
2: from /home/wim/.rvm/gems/ruby-2.5.1-latest/gems/hamlit-2.9.1/lib/hamlit/compiler.rb:79:in `compile_script'
1: from /home/wim/.rvm/gems/ruby-2.5.1-latest/gems/hamlit-2.9.1/lib/hamlit/compiler/script_compiler.rb:19:in `compile'
/home/wim/.rvm/gems/ruby-2.5.1-latest/gems/hamlit-2.9.1/lib/hamlit/compiler/script_compiler.rb:19:in `require': cannot load such file -- temple/static_analyzer (LoadError)

As is evident, this is with ruby v2.5.1.

By experimentation, I found that the error disappears if I add a require to the top of lib/hamlit/compiler/script_compiler.rb:

require 'temple/static_analyzer'

Would you mind checking this out, and ensuring it doesn't happen any more?

For completeness, I mention that the same thing happens with Haml, so it might be an issue with the temple gem. However, since the require is so effective, I'm hoping that you can compensate within the Hamlit code.

wimrijnders commented 5 years ago

I feel obliged to add this addendum.

When removing the require as above, the given error does not occur again. I have no explanation for this; perhaps it has something to do with the inner working of gem (v2.7.8)?

k0kubun commented 5 years ago

Would you mind checking this out, and ensuring it doesn't happen any more?

Temple v0.8.0 has https://github.com/judofyr/temple/blob/v0.8.0/lib/temple/static_analyzer.rb and Hamlit v2.9.1 requires Temple >= 0.8.0.

This is very unlikely to be an issue inside Hamlit. The issue seems to be in your installation. So I'll close this as an issue of Hamlit.


wimrijnders commented 5 years ago

@k0kubun Thanks for responding so rapidly! I really appreciate it when open source maintainers are on top of things. I've been there, know how hard it gets.

I feel the urge to point out that i'm not dealing directly with the gem you mentioned, Temple. From my point of view, I'm trying to use Hamlit and it doesn't work. While I do understand your point of view, if this is a categorical thing then you can expect more people coming here with this issue.

Tried all you said, no effect. This is a brand-new debian install and everything was installed from scratch so newest everything. If you closed the issue, is there any point in responding to your questions?

k0kubun commented 5 years ago

You overlooked

Please share your current full gem list output

it's still worth looking at.

This is a brand-new debian install and everything was installed from scratch so newest everything

I feel this is not an answer to "How did you install Hamlit" either. Please describe all exact commands you used in your scratch environment.

wimrijnders commented 5 years ago

No, I didn't overlook it. You closed the issue, indicating that you do not wish to proceed further with it. Forgive me for losing interest.

But OK I'll humour you:

async_sinatra (1.3.0, 1.2.1)
bcrypt (3.1.12, 3.1.11)
beaneater (0.3.3)
bigdecimal (default: 1.3.4)
bundler (default: 1.16.6)
bundler-unload (1.0.2)
byebug (10.0.2)
childprocess (0.9.0, 0.5.9)
cmath (default: 1.0.0)
csv (default: 1.0.0)
daemons (1.2.6, 1.2.3)
date (default: 1.0.0)
dbm (default: 1.0.0)
deep_merge (1.2.1, 1.0.1)
did_you_mean (1.2.0)
em-websocket (0.5.1)
etc (default: 1.0.0)
eventmachine (1.2.7, 1.2.0.1)
executable-hooks (1.6.0)
fcntl (default: 1.0.0)
ffi (1.9.25, 1.9.13)
fiddle (default: 1.0.0)
fileutils (default: 1.0.2)
gdbm (default: 2.0.0)
gem-wrappers (1.4.0)
git-version-bump (0.15.1)
haml (5.0.4)
hamlit (2.9.1)
hashdiff (0.3.7, 0.3.0)
http_parser.rb (0.6.0)
inifile (3.0.0)
io-console (default: 0.4.6)
ipaddr (default: 1.2.0)
json (default: 2.1.0)
logger (1.2.8)
mail (2.7.1)
mini_mime (1.0.1)
minitest (5.10.3)
mustermann (1.0.3)
net-telnet (0.1.1)
openssl (default: 2.1.0)
power_assert (1.1.1)
psych (default: 3.0.2)
rack (2.0.6, 1.6.4)
rack-contrib (2.1.0)
rack-legacy (1.0.0)
rack-protection (2.0.4, 1.5.3)
rack-proxy (0.6.5)
rack-reverse-proxy (0.12.0)
rake (12.3.0)
rb-fsevent (0.10.3)
rb-inotify (0.9.10)
rdoc (default: 6.0.1)
require_all (2.0.0)
rubygems-bundler (1.4.5)
rvm (1.11.3.9)
sass (3.7.2)
sass-listen (4.0.0)
scanf (default: 1.0.0)
sdbm (default: 1.0.0)
sinatra (2.0.4, 1.4.7)
sqlite3 (1.3.13)
stringio (default: 0.0.1)
strscan (default: 1.0.0)
temple (0.8.0)
test-unit (3.2.7)
thin (1.7.2)
thor (0.20.3)
tilt (2.0.8, 2.0.5)
webrick (default: 1.4.2)
xml-simple (1.1.5)
xmlrpc (0.3.0)
zlib (default: 1.0.0)

If there's one aberration in this, it's that tilt is not at the latest version v.2.0.9. There's some component in my install that insists on using v.2.0.8.

I feel this is not an answer to "How did you install Hamlit"

See above. But the answer is gem install hamlit. The rest are either done with gem install or with bundle install using Gemfiles.

k0kubun commented 5 years ago

You closed the issue

I just meant this is not an issue of Hamlit's implementation (as this is a place to collect Hamlit's issue). This doesn't mean I do not help you.

hamlit (2.9.1) temple (0.8.0)

Interesting. Given that temple v0.8.0 is installed properly (and you followed gem uninstall temple && gem install temple now), some remaining possibilities are:

By the way, Haml is also using temple/static_analyzer (because I'm also maintaining that part of temple). And I found Haml is relying on autoload and not writing temple/static_analyzer.

That said, this could be an issue inside Hamlit itself, due to the complexity of underlying autoload for temple/static_analyzer. As I'm not a fan of autoload, I didn't have enough understanding of its risk and take that in consideration.

I'll take a look around it and possibly remove require 'temple/static_analyzer' as you said.

wimrijnders commented 5 years ago

This doesn't mean I do not help you.

OK thank you. Sorry for misunderstanding then.

Some of your already-required gems are breaking your LOAD_PATH, or has lib/temple and it crashes load order.

Any way I can check this?

rubygems (in 2.5.1) are somehow broken and letting Hamlit require Temple v0.8.0's code

This was my first thought when confronted by this. EDIT: This gave me the idea to look in the issues of rubyggems, to see if someone reported something similar. No such luck.

By the way, Haml is also using temple/static_analyzer

Yes. I posted a very similar bug report to them as well (so, also to you again! :smile: )

I'll take a look around it and possibly remove require 'temple/static_analyzer' as you said.

Actually the thing is, it wasn't there. As reported above, after adding the require all worked well. Same thing with Haml.

k0kubun commented 5 years ago

Actually the thing is, it wasn't there. As reported above, after adding the require all worked well.

Oh right... misunderstood again. Hamlit is not requiring it either. So, the problem is in autoload usage. By the way, if possible, could you try other Ruby versions, like 2.5.3 or 2.4.5? This could be a bug inside Ruby's autoload (I'm maintaining Ruby as well).

So, as both of us seem to be busy to prepare reproducible code to understand the situation, I'll just add explicit require.

Same thing with Haml.

I'll apply a similar change to it too.

k0kubun commented 5 years ago

I added your explicit require in v2.9.2. Please try it.

wimrijnders commented 5 years ago

:+1: Updated to 2.9.2, confirmed issue is fixed. Can't check Haml yet, but if the fix is the same, I'm confident that it will work..

Thank you sincerely for your very fast help. Also, thank you for putting up with me.

wimrijnders commented 5 years ago

This could be a bug inside Ruby's autoload

Not sure if it's a bug but something definitely changed. I have the situation now that require_all can't find all the require's. Eventually, I solved it by putting this ugly thing at the top of my entry file:

$script_path = File.expand_path(File.dirname(__FILE__)) + '/ruby'
$:.unshift($script_path) unless $:.include?($script_path)

...but still it's silly because previously it found everything no problem.

(I'm maintaining Ruby as well).

My god, you're deicated! I was a maintainer (still am officially) for vis.org for over a year, and it was a fun but really intensive time. So hearing you maintain at least 3 OS projects earns my full respect.