Replace "poetry" dependency with "poetry-core"

[enpaul]

poetry-core is a project to produce a lighter weight version of core poetry functionality specifically to better support PEP-517 build systems.

However (based on reading the published goals as of the 1.0 RC1 release) I believe it will also contain all the functionality necessary for this plugin to function.

Using the poetry-core package instead of poetry would give this project two main advantages:

1. By design the poetry-core dependencies are considerably lighter than those of poetry. This was done to speed up the creation of PEP-517 build environments, but here it would reduce the size of this project's dependency chain. Since this is supposed to be a minimalist, lightweight plugin that just bridges the functionality of Tox and Poetry it would be nice if it did not need to install a huge number of dependencies to function.
2. The poetry-core package will provide the poetry.core module namespace and replace a decent amount of functionality currently in the main poetry module. This means, at minimum, this plugin will need to be updated to be compatible with Poetry 1.1.0+ (which will use poetry-core). However due to the design goals of poetry-core it will, by necessity, have a more stable API than some of the more esoteric elements of poetry that this plugin currently imports. Using poetry.core instead of poetry will reduce the likelihood of future updates to Poetry breaking this plugin.

I need to confirm what- if any- functionality of poetry that this plugin needs is not included in poetry-core and determine how to work around those limitations. At minimum I suspect some of the types that are currently imported will not be available, but I have not confirmed this yet.

[enpaul]

This is blocked for the moment, on several components:

• poetry-core does not support reading the lockfile (Make core aware of poetry lock files python-poetry/poetry-core#83)
  • Required for the locker, locked repository, and puzzle provider
• poetry-core does not support environment installation
  • Required IO, poetry venv, and pip installer

[johnthagen]

This would be very nice. The issue we ran into is that if you put tox-poetry-installer in the dev-dependencies and install into a production environment (such as a Docker container) using poetry install --no-dev, because tox-poetry-installer depends on poetry, this would uninstall poetry itself since in a Docker container, there is typically no need for a separate virtual environment for Poetry itself.

We needed to move back to the [tox] requires method for now.

[enpaul]

@johnthagen As a workaround for the issue I believe that installing poetry using the get-poetry script will prevent it from uninstalling itself from the project environment. I haven't tested this exact scenario, but I had a similar issue in a docker build where my poetry installation existed alongside my project installation, and switching to installing poetry via the script fixed it for me.

[johnthagen]

@enpaul Thanks, I suspected something like that would help as well.

[enpaul]

Taking another look at this one. The main blocker here is definitely the lockfile support in poetry-core. Parsing and handling lockfile conditions is something I would really like to avoid having to reimplement for this plugin.

That said the other blocker I highlighted above (pip installation support) is something I think we can work around. Poetry is MIT licensed so I think the PipInstaller class (and any other necessary plumbing for it) should be fairly simple to vendorize without too much trouble. Before doing this though I will want to review what is in the PipInstaller class to make sure it's viable.

Once both of those elements are unblocked I can drop the poetry dependency.

[johnthagen]

Parsing and handling lockfile conditions is something I would really like to avoid having to reimplement for this plugin.

Yes, I totally agree with this. I'd never want to ask a package like this to reimplement something that should otherwise be shared with poetry. We have working work-arounds and understand the poetry ecosystem still has a little maturing to do.

Thanks!

[johnthagen]

@enpaul FYI, on the main README this is checked as complete, even though it looks like actually it was just deferred until the stable release.

[enpaul]

Ah, good catch @johnthagen . I'll update the readme

[enpaul]

Update on this issue: this is currently blocking both the 1.0 release of this plugin and the upgrade to Tox 4 compatibility (as noted elsewhere, there are compatibility issues between the versions of importlib-metadata required by Tox 4 and Poetry 1.x). Once this issue is resolved I'll plan to build and release version 1.0 that includes Tox 4 support and drops the Poetry dependency, which solves another bunch of issues (including #82 and #79)

The singular blocker on this right now is lockfile processing in poetry-core, being tracked in python-poetry/poetry-core#83. Once that's merged and/or the functionality is otherwise added this issue becomes unblocked.