Transition ACA-Py to use poetry

[dbluhm]

With #2247, we're now running on Python 3.9 and there are a number of dependency updates that I'm planning to make. This could be a good opportunity to make some improvements to our dependency management.

I am personally a fan of poetry -- it's dependency resolution is superior to pip's and it's got several nice-to-haves like builtin virtual environment handling and build and publish commands. There are still some limitations; it doesn't support platform specific builds and bundling binaries so it is unsuitable for projects like Askar right now but I think ACA-Py fits well into poetry's strengths. Externally, this transition should be seamless for ACA-Py users, whether they're consuming ACA-Py via PyPI or container image.

I'm content with our current setup.py and requirements.* files but my team has been pleased with poetry in our projects over the past couple of years.

Thoughts?

@swcurran @usingtechnology @ianco @TimoGlastra

https://python-poetry.org/

[usingtechnology]

I like poetry, particularly for development I prefer it for dependency management. I would not be opposed to bringing it into ACA-Py.

I'm not sure how the various requirements files (askar, bbs, indy, dev) would work. With poetry, i assume they would be in dependency groups, but a developer without poetry (or who does not want to use it) can't leverage those groups through pip?

Maybe a few things to prove out, but certainly onboard with supporting poetry.

[dbluhm]

The askar, bbs, and indy requirements I think would make sense as an "extra;" these behave like pip extras and enable the user to install them using commands like pip install aries-cloudagent[askar] (which I believe is how the setup.py is configured currently anyways). The dev dependencies would be a dependency group; developers working on ACA-Py would need to use poetry (there might be some workarounds to continue using pip but install deps from a poetry.lock) and use it to install those dependencies.

[usingtechnology]

when this work is tackled, can we do our best to update dependencies? I recently (using acapy 0.8.2) had issues doing plugin updates where packaging was in conflict with (i think black?) and i also had to specify an explicit version for typing-extensions to resolve. i know we can't possibly know all of what is out there, but it would be nice if we could reduce the potential for conflicts.

[dbluhm]

@usingtechnology absolutely; I agree that this is sorely needed. We've run into similar issues.

[dbluhm]

Added high priority label; I think updating dependencies is becoming increasingly urgent and having this in place would be helpful.

[swcurran]

@Gavinok

[hiteshgh]

Assigned to Gavin

[hiteshgh]

@usingtechnology to assit @Gavinok with PR test issues