Open mtkennerly opened 1 year ago
This may be related, or may need it's own issue (maybe in the poetry-dynamic-versioning repo)...
I have a case where I have an internal library to a script that we have installed as a submodule, then refer to it in the dependency section of pyproject.toml using direct path reference:
That library is also a Poetry Python project, and both use poetry-dynamic-versioning to update the version.
poetry install
it finds the '0.0.0' version, I assume from pyproject directly, and decides it needs to downgrade from 1.0.1 to 0.0.0.Ideally Poetry would trigger the plugin and somehow get the correct VCS-inspired version rather than the 0.0.0 text in pyproject.toml.
poetry install
command.I'm working on a small plugin that needs to do some cleanup after a poetry run
, it would be nice if this could get fixed
@LightCC I think that would be a separate issue. It also came up in the poetry-dynamic-versioning repo here: https://github.com/mtkennerly/poetry-dynamic-versioning/issues/154#issuecomment-1787478235 . I think you're right that Poetry is showing the static version from pyproject.toml before it's far enough along in the process to trigger the plugin.
-vvv
option) and have included the output below.Issue
On non-Windows systems,
poetry run
usesos.execvpe
:https://github.com/python-poetry/poetry/blob/6e942983dff1bcc6d307c7704e8159df0c959a16/src/poetry/utils/env/generic_env.py#L90-L91
Because of how this function replaces the current process, a plugin cannot respond to the
TERMINATE
event.atexit
hooks are also not called.Could
subprocess.Popen
simply be used for all systems instead of Windows only?My use case is that my plugin makes some temporary modifications to set the version number, and it needs to revert them when the command is done. Right now, I just have the plugin ignore
poetry run
andpoetry shell
since it can't clean up after them.