Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugins cannot respond to TERMINATE event on non-Windows systems after poetry run #8092

Open
4 tasks done
mtkennerly opened this issue Jun 11, 2023 · 3 comments
Open
4 tasks done
Labels
area/plugin-api Related to plugins/plugin API area/windows For Windows-specific issues kind/bug Something isn't working as expected status/triage This issue needs to be triaged

Comments

@mtkennerly
Copy link

mtkennerly commented Jun 11, 2023

  • Poetry version: 1.5.1
  • Python version: 3.10.7
  • OS version and name: Windows 11
  • pyproject.toml: Any
  • I am on the latest stable Poetry version, installed using a recommended method.
  • I have searched the issues of this repo and believe that this is not a duplicate.
  • I have consulted the FAQ and blog for any relevant entries or release notes.
  • If an exception occurs when executing a command, I executed it again in debug mode (-vvv option) and have included the output below.

Issue

On non-Windows systems, poetry run uses os.execvpe:

if not self._is_windows:
return os.execvpe(command[0], command, env=env)

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 and poetry shell since it can't clean up after them.

@LightCC
Copy link

LightCC commented Nov 13, 2023

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:

image

That library is also a Poetry Python project, and both use poetry-dynamic-versioning to update the version.

  • When Poetry installs the submodule it builds it and the build ends up with the correct version (1.0.1), but when running 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.
  • It also reports the parent project as version 0.0.0
  • image

Ideally Poetry would trigger the plugin and somehow get the correct VCS-inspired version rather than the 0.0.0 text in pyproject.toml.

Note

  1. The parent project in the .venv/Lib/site-packages shows up as version 0.0.0 (despite git version being 0.0.1)
  2. The library/submodule version is actually installed as 1.0.1 in site-packages, rather than the 0.0.0 reported by the poetry install command.

@Matthieu-LAURENT39
Copy link

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

@mtkennerly
Copy link
Author

@LightCC I think that would be a separate issue. It also came up in the poetry-dynamic-versioning repo here: mtkennerly/poetry-dynamic-versioning#154 (comment) . 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/plugin-api Related to plugins/plugin API area/windows For Windows-specific issues kind/bug Something isn't working as expected status/triage This issue needs to be triaged
Projects
None yet
Development

No branches or pull requests

4 participants