Take Poetry's lock file into account

[sinoroc]

There should be a way to instruct Tox to install the pinned versions as read from Poetry's lock file.

UX:

Probably from a UX point of view it could look like this:

[testenv:something]
# ...
poetry_use_lock_file = True

Related:

• What if poetry.lock and poetry-core, used by the plugin, are incompatible? #10
• Make core aware of poetry lock files python-poetry/poetry-core#83

[sinoroc]

I believe I know more or less how to get started on this. But before I start, there is still one thing that somewhat bothers me about this, to make sure this feature is really worth it and what it should do:

How would that be any better than having commands = poetry install [--no-root]?

From what I understood, reproducibility is very important. The combination of libraries should be the exact same in the testenv as it will be in production. But in Tox we would most likely need to delegate to pip (or whatever the install_command is). There is always a risk of having a slightly different behaviour: meaning a slightly different combination of libraries (hopefully not, if we check the hashes and what not). So how do we mitigate that risk or check that the libraries are exactly the same as in the lock file?

Possible reasons why it would be better than poetry install:

• we can not guarantee that the poetry binary is available, and we do not want to install it inside the testenv
  • but we still have at least pip (setuptools) in the testenv
  • how is the production environment? does it have pip or poetry inside?
  • how is the application and dependencies installed on the production environment
• ...

@mikenerone

[mikenerone]

@sinoroc You may well be right that it's not better - my thinking has been shifting on this for the last week or so. Out of necessity, I've already switched back to a tox config that does it that way. The very visible problem with this approach was that devs needed to explicitly include the separate poetry testenv in the tox command line, but I thought of a variation that cleaned that up (putting poetry it in tox's own env with the global requires setting) so that's not an issue anymore, and it seems to be working well enough. :|

[fredrikaverpil]

I agree with @mikenerone that it works quite well with {toxworkdir}/.poetry/bin/poetry install --no-root. However, this solution is not cross platform compatible.

I went and added a pull request towards tox so to add a keyword for the "bin" folder (which would then get replaced with "bin" on posix and "Scripts" on Windows). However, one of the maintainers did not like this. They also disapproved this entire approach of mixing in the delegation of installing the venv to poetry like this, basically because accessing binaries outside of the tox testenv was not ideal in their mind.

You can read the full thread here. And why not get in touch with the maintainers to receive feedback, perhaps?

Either way, I would rather use your plugin than call {toxworkdir}/.poetry/bin/poetry install --no-root. I presume you could make this cross platform quite easily too. 😋

[sinoroc]

The very visible problem with this approach was that devs needed to explicitly include the separate poetry testenv in the tox command line

@mikenerone You mean you used to run tox -e poetry,somethingelse or tox -e poetry && tox? So poetry is not already installed before starting to run tox? So you only install tox (globally?), but not poetry? I see...

[sinoroc]

They also disapproved this entire approach of mixing in the delegation of installing the venv to poetry like this, basically because accessing binaries outside of the tox testenv was not ideal in their mind.

@fredrikaverpil I had read most of that discussion already. I must say I agree with them, mixing the testenvs feels weird. Although I see your point. There has to be a better way to solve this.

On the other hand, it is strange when they say that they consider allowlist_externals a red flag. Honestly I do not think that installing the test tools (or poetry, or even pip) in the testenv is a better idea. I'd much rather have the tools isolated, and point them at the environment that should be acted upon (tested), so we need allowlist_externals, but obviously for most of the tools there is no other way than installing them inside the testenv. For static tools (those that only read the code without executing it), it should be no problem, but for the others such as pytest (that do need to run the code) it seems impossible.

So on that front, poetry is on the right track. It doesn't need to be in the env, it can act on any env that is activated. Also the work in progress that would remove the need to install pip, setuptools, etc. in the env is very welcome.

[mikenerone]

@mikenerone You mean you used to run tox -e poetry,somethingelse or tox -e poetry && tox? So poetry is not already installed before starting to run tox? So you only install tox (globally?), but not poetry? I see...

Yes, we used to have to do e.g. tox -e poetry,py36.

To answer your second question, devs install both Poetry and tox globally on their systems. The tox requirements = approach is intended primarily for the build servers, and provides at least four benefits there (all closely related):

1. Simply less for DevOps to maintain in terms of installed software on those servers. Only tox >= 3.8 is required.
2. Also less knowledge of package specifics required by DevOps. All they have to know is that, for Python projects, all Jenkins needs to do to make a package is tox -e wheel, we we devs will make sure that does the right thing for whatever build system that project happens to be using.
3. Even if all projects used the same build system (Poetry, obviously :P, but this isn't the case right now), it's conceivable that different projects might need different versions of Poetry. Keeping the Poetry installs isolated to tox envs allow us to define Poetry version constraints on a per-project basis.
4. Similarly, it allows us to define required poetry plugins (with version constraints) or other utility packages on a per-project basis. (Granted, there's no formal plugin system yet, so such plugins are hacks at the moment, but in any case, a real plugin system is on the roadmap.)