Unable to access different Lua versions as described in the README

[redruin1]

The readme provides this sample to indicate how to select different versions of Lua to use:

try:
    import lupa.luajit20 as lupa
except ImportError:
    try:
        import lupa.lua54 as lupa
    except ImportError:
        try:
            import lupa.lua53 as lupa
        except ImportError:
            import lupa

However, this seems out of date, as this fails to import when running on the current master branch:

>>> import  lupa.lua52 as lupa
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'lupa.lua52'

Setup process:

> git clone https://github.com/scoder/lupa.git
> cd lupa
> git submodule update --init --recursive
> python setup.py install

Going to __init__.py and manually changing _newest_lib to force a particular version seems to work:

_newest_lib = __import__('lua52', level=1, fromlist="*", globals=globals())

I didn't see any other relevant functions defined in the module's init. What's the proper way to import LuaRuntime 5.2 instead of LuaRuntime 5.4?

Windows 10, Python 3.10, lupa 2.0a1

[scoder]

What you describe actually works for me (import lupa.lua52). I'm suprised how you can import .lua52 from the package if you cannot import lupa.lua52 from outside. That seems wrong, but not from the side of Lupa.

Can you positively confirm that there is a file lupa\lua52.cpython-...pyd in your installation?

You also mentioned that this happens on Windows. I'm not aware of any related differences of Python's import system on that platform (besides the usual upper/lower case naming issues). Could you try to investigate this a bit further?

[redruin1]

Alright, I think this was user error. Turns out if you use the source distribution your directory structure matters:

> mkdir lupa_testing
> cd lupa_testing
lupa_testing> python -m venv .
lupa_testing> Scripts\activate.bat
(venv) lupa_testing> git clone https://github.com/scoder/lupa.git
(venv) lupa_testing> cd lupa
(venv) lupa_testing\lupa> git submodule update --init --recursive
(venv) lupa_testing\lupa> pip install -r requirements.txt
(venv) lupa_testing\lupa> pip install .
(venv) lupa_testing\lupa> python                         # While we're still in the cloned repo!
Python 3.10.0 (tags/v3.10.0:b494f59, Oct  4 2021, 19:00:18) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import lupa.lua52 as lupa
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'lupa.lua52'

However, if I pull back to lupa_testing with the same code, it works:

(venv) lupa_testing\lupa> cd ..
(venv) lupa_testing> python
Python 3.10.0 (tags/v3.10.0:b494f59, Oct  4 2021, 19:00:18) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import lupa.lua52 as lupa52
>>> import lupa.lua53 as lupa53
>>> import lupa.lua54 as lupa54

In my other repo I was installing the source directly to the site-packages folder in the environment and then installing it "in-place"; making the lupa github source and the installed lupa build the same folder, which I suppose now explains why it wasn't working correctly. I guess that makes this user error, unless lupa is expected to work under that circumstance.

While I have your attention, can I tack on a support question as well? Even with my catastrophic directory structure, I managed to get 5.2 working in my other python module and I'd like to distribute it to fix this issue. I know that the wheels for 2.0 aren't done yet, but is it possible to distribute the master branch as source (along with cython) and have pip/setuptools automagically build + configure it on install, at least until the 2.0 release?

[redruin1]

Doesn't seem possible to use the master branch as a dependency; I think I need to make it editable in order to build the binaries which doesn't (at a glance) seem possible. I guess I'll just wait for the wheels when they're baked. Closing.