Stronger checks for existence of config gem

[paracycle]

Motivation

Solve a problem experienced with a Shopify project.

Just checking for the existence of a Config constant does not necessarily guarantee that the config gem is loaded, since an application could define their own top-level Config constant.

Implementation

It is better to check for the existence of Config::VERSION and Config.const_name as well, to be reasonably sure that the constant is coming from the gem.

Tests

All existing tests pass

[EdwardGallant]

this might be just kicking the can down the road a bit 🤔 Long term does the constant need to be moved to a namespace?

[paracycle]

This is not a constant from Tapioca. This is a compiler for the config gem and this line is trying to detect if the config gem is loaded or not: https://github.com/rubyconfig/config

So, we can't rename the constant. This is the best way that I know if checking if the config gem is loaded without false positives.

[EdwardGallant]

interesting. thanks for the explanation. This is a rather precious namespace for a dependency of a dependency to eat 🤔

options:

• fork & rename
• rename at runtime

irb(main):001:0> module Bob; end
=> nil
irb(main):002:0> Bob
=> Bob
irb(main):003:0> Henry = Bob
=> Bob
irb(main):004:0> Henry
=> Bob
irb(main):006:0> Object.send(:remove_const, :Bob)
=> Bob
irb(main):007:0> Henry
=> Bob
irb(main):008:0> Bob
Traceback (most recent call last):
        4: from /usr/bin/irb:23:in `<main>'
        3: from /usr/bin/irb:23:in `load'
        2: from /Library/Ruby/Gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in `<top (required)>'
        1: from (irb):8
NameError (uninitialized constant Bob)
irb(main):009:0> 

• remove this dependency, find another way to load configuration files (if it's a light enough lift, probably preferable)

just some ideas. The metaprogramming idea might be tricky depending on loading order.

[paracycle]

Again, this is not a dependency Tapioca brings in, Tapioca just tries to do the right thing for apps that might be using this gem. We have no control over how applications use this gem, so we can't do any runtime manipulations.

[EdwardGallant]

gotcha, I misunderstood.

[alexcoco]

Looks good to me to fix the issue but I do agree that maybe this ought to be in a namespace owned by Tapioca.

[paracycle]

Looks good to me to fix the issue but I do agree that maybe this ought to be in a namespace owned by Tapioca.

#1802 (comment)