Use poetry-core as the build backend instead of full poetry

[hroncok]

No description provided.

[stanislaw]

Thank you for your contribution! I will get to resolve the 3.6 stuff later today. Could you provide a small explanation of how this change improves the build process? My context: I was simply not following the Poetry developments for quite some time, so I don't understand which improvement your change brings.

[hroncok]

Right. Poetry is a full-blown dependency management and virtual environment tool used for development. Poetry core is just the build backend to build wheels from poetry configuration. Both things are developed by the same people and Poetry uses Poetry core. This way, the dependency footprint to build the wheel is smaller. My primary motivation is Fedora and EPEL. We don't yet have Poetry or Poetry core packaged in EPEL and this makes the next steps a tad easier for us (as we would only need Poetry core).

[stanislaw]

Thanks a lot for the explanation! I will fix the CI very soon by pushing right to this branch/PR.

[stanislaw]

I have fixed the CI for macOS and Linux and disabled it temporarily for Windows because I could not make Poetry to pick the correct Python version. On each build machine, instead of picking the right version, it was always picking the system's 3.11.

I have to admit that I find it quite inconvenient to maintain Poetry long-term. Do you happen to know a more lightweight approach for developing and packing Python projects that would not require Poetry?

In my other project StrictDoc, I have removed Poetry quite some time ago and have been happy since then but there I am using some custom code that sets up the virtual environment for all my development tasks. Is there a non-Poetry approach but also something that helps with virtual environments stuff?

I have just released the 0.0.23.

[hroncok]

For a library like this, I'd probably use hatch(ling) for packaging + tox for virtual environment mamagement.

[stanislaw]

For a library like this, I'd probably use hatch(ling) for packaging + tox for virtual environment mamagement.

Looking at this issue and this one, it looks like I could consider moving from Invoke to Nox. The hatch(ling) I am already using for StrictDoc.

[rathann]

[...]

I have just released the 0.0.23.

Can you please tag it as well?

[stanislaw]

Can you please tag it as well?

Done!