Mitigate "UNSAFE_DEPENDENCIES" issue

[enpaul]

This issue is related to finding a work around to python-poetry/poetry#1584. If the noted functionality is removed so that the "unsafe" packages can be installed to the lockfile then no further work is needed then this issue can be closed. However in the meantime a workaround is needed.

Currently the behaviour of the plugin when encountering a dependency Poetry classifies as unsafe is to a) log a warning indicating that it will not be installed and b) skips it without installing. This is a disaster waiting to happen.

I believe that the best way to solve this problem (which admittedly is still not a great solution) is to hot-load dependencies into the Tox environment config to be installed using the legacy backend. Even though Poetry provides the version of an unsafe dependency in the Package().requires attribute of a package that requires it, the plugin doesn't have any information about the dependencies of the unsafe packages because they aren't in the lockfile. If, for example, Tox installs setuptools==1.2.3 by default, a dependency requires setuptools==2.3.4 and the dependencies of the newer version are different (not unreasonable for a major version bump) then those updated dependencies cannot be installed by the plugin.

The most approachable solution is to add these as unlocked dependencies to the Tox environment config so that the default backend can install them and their dependencies. This is dangerous as it exposes the environment to all the problems this plugin is designed to solve, but it does solve trivial functionality issues for packages that depend on these packages Poetry has classified as unsafe.

Hopefully a more robust solution will be made upstream eventually.

[enpaul]

Thinking about this more: this should probably be a configurable setting. Some bool setting like enable_unsafe_deps = true|false to dis/allow this behaviour for a specific testenv. Not sure yet what the default should be, but I'm leaning towards defaulting to true.

[enpaul]

Another note about this one: the solution I proposed in the original issue actually won't work entirely as I hoped. Modifying the env dependencies on the tox environment will cause the same problem that #18 aimed to fix. Since the as-written dependencies won't match the as-installed (from tox's perspective) it will always trigger a recreate action.

I'm not sure what the best course of action is here. I'd really like to avoid having to call pip via subprocess in this plugin, but it's looking more and more like that'll end up being necessary.

[enpaul]

This issue was determined to be out of scope for this plugin and will not be implemented.

Ultimately this plugin is trying to bridge the functionality of Tox and Poetry, and Poetry does not support installing these packages while Tox does. It's personally frustrating because conflicts with these packages have given me problems before, but it's not reasonable to reimplement package installation logic in this plugin. As a compromise the unsafe dependencies are now more thoroughly documented along with a workaround.