Getting rid of importlib dependency

[Pirulax]

Hello!

The library is overall very good, and useful, thank you for it! I just have one problem, it being that the library depends on importlib, which wouldn't be an issue, if I wouldn't be compiling my program with Nuitka. I do realize this isn't an issue with aiolimiter, but I was wondering if getting rid of it may be possible? See Nuitka issue regarding importlib here.

Thank you.

[mjpieters]

We use importlib to avoid having to track version numbers in multiple places.

I'd very much like to switch to the poetry dynamic version plugin, but that is blocked on Poetry 1.2 being released. Poetry 1.2 has reached beta status, so it'll probably happen in the next few months.

I don't have much bandwidth to spare to remove the dependency earlier, sorry.

[Pirulax]

Hello! So, you suggest we wait for Poetry 1.2 to be officially released as stable?

[mjpieters]

That's the plan

[qarkai]

I try to build using python -m build --wheel --no-isolation and get following error

Traceback (most recent call last):
  File "/usr/lib/python3.11/site-packages/pyproject_hooks/_impl.py", line 321, in _call_hook
    raise BackendUnavailable(data.get('traceback', ''))
pyproject_hooks._impl.BackendUnavailable: Traceback (most recent call last):
  File "/usr/lib/python3.11/site-packages/pyproject_hooks/_in_process/_in_process.py", line 77, in _build_backend
    obj = import_module(mod_path)
          ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1206, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1178, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1128, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1206, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1178, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1142, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'poetry.masonry'

ERROR Backend 'poetry.masonry.api' is not available.

Is importlib cause of this?

[mjpieters]

No, that's because you then need to manually install the poetry-core build dependency. This is specifically documented when using --no-build-isolation. Not sure why build doesn't make this more explicit?

[mjpieters]

Ah, no, this is a different issue. The build dependency for the last release made is still poetry (not poetry-core) and more recent releases of poetry (1.1.0 and up) now depend on poetry-core 1.0.0a5 and newer. Your import error suggests your installation has mismatched poetry and poetry-core releases installed.

I think you can fix this by upgrading poetry and poetry-core first.

Still not related to the importlib dependency here (which poetry plugins still don't satisfyingly make easier to remove).

[qarkai]

I have poetry 1.4.2 and poetry-core 1.5.2 installed. The latest versions according to https://github.com/python-poetry/poetry/releases and https://github.com/python-poetry/poetry-core/releases. Also I can build package with same build system, e.g. aiofiles. Should we continue this in separate issue?

[mjpieters]

Hrm, I can indeed reproduce this locally, but have no idea what's going on. build seems to have issues installing the build hook configured. Yes, this is probably a separate issue, could you create one?

[mjpieters]

Revisiting the poetry_dynamic_versioning plugin, I must say I dislike the complexity that introduces. The importlib path makes pyproject.toml the source of truth, and is a very simple and very effective method.

There have been no other requests to get rid of the importlib.metadata dependency, and it appears that nuitka is the only tool that doesn't support importlib. I can see from their issue tracker that this is a common issue for other packages as well, so hopefully the nuitka maintainers will move to find a solution for this. Other Python-to-EXE compilation tools manage this by baking in the metadata and providing a custom importlib.metadata implementation to unlock that information, so I'm of the opinion that nuitka should too.

As such I'm going to close this issue as 'not planned'.

[mjpieters]

Even better, reading through Nuitka/Nuitka#1793 it appears that the tool now supports importlib.metadata natively as of version 1.1.