correctly handle module that only set package.loaded

[boucman]

running these two scripts yield different results
(these assume you have luasec installed, apt-get install lua-sec under debian)

print(require("ssl.https"))

will print table: 0x25ef070 (or similar)

require=require("require").requireprint(require("ssl.https"))

will print nil

This is because ssl.https uses the "module" function and that function sets package.loaded["ssl.https"] which, in turn, means the function doesn't have to return anything.

According to lua documentation (and the way the original require works) this is a legal thing to do and require should return the value of package.loaded["ssl.https"] in that case

[tst2005]

Hello,

You fixed the require52 but I think you will got the same issue with the require51 and it needs the same fix.

[tst2005]

I start to make a full require behavior tests ...
Take a look at https://github.com/tst2005/lua-require-tests

[boucman]

i'll have a look, but I only use 5.2 on a regular basis...

[boucman]

ok, fixed

[pygy]

Thanks, this is a very good catch, quite embarrassing, to be honest :-)

The test suite most welcome. You may want to add package.loaded[modname] = nil after line 19.

I'll review it all tomorrow.

[boucman]

@pygy are you waiting for a new patch for me with the fix ? i'm not sure what you want

• you probably mean before line 19, since code after error() wouldn't be reached
• even if that's the case, we are at a stage where we havn't set package.loaded[modname] ourselves, so we might as well not touch it.

Of course, if you think that's important I can add it, but i'm not 100% convinced...

[pygy]

@boucman that was about the test suite, not your patch. At first glance, it looks fine, but I'll have to review it more thoroughly.

I've had a hectic week (baby born earlier today after a problematic pregnancy for my gf. All's fine now :-)), which left me little time for this. Hopefully I'll have time tomorrow evening.

[boucman]

no worries, take your time... this is already fixed in the local copy of darktable, so we are not blocked by this bug

my question was more because of the first part : i.e did you expect anything from me....

since that's not the case, I'll just wait. No problem

[boucman]

any news ? (I don't mind, I have a local fix, but other users might get bitten by this bug)

[pygy]

I'll look into this later today.

[boucman]

awesome, thx

[pygy]

Thanks a lot. Now I must do the Luarocks dance :-)

[pygy]

@tst2005 could you send a pull request with your test suite so that you're correctly credited in the Git log and project stats?

[tst2005]

@pygy ok, see #7