[quote="Jérôme Pouiller, post:8, topic:67580, full:true, username:jerome-pouiller"] hmm… so the idea is “a python package should never call a binary provided by another package”, that’s it? Yet, I believe it is a common pattern. [/quote]
Not quite, as the behaviour you're describing is technically a bug (or at least a missing feature) in `west` rather than anything behaving unexpectedly in any of the packaging tools. Virtual environments only guarantee that `sys.path` will be adjusted - it is specifically venv activation that manipulates `PATH`. For subcommand invocation like that to work reliably (without requiring an activated virtual environment), there are a few potential ways to do it: 1. If a dependency offers a Python API, invoke it that way rather than via its CLI 2. Invoke the dependency provided subcommands via `[sys.executable, -m, relevant_module_name]` rather than via their installer-generated CLI wrapper scripts. How viable this is depends on whether or not the dependencies involved have defined a `-m` compatible CLI invocation (there may not be a suitable module to execute that's equivalent to running the wrapper script) 3. Invoke the dependency subcommands via `[sys.executable, -c, "from entry_point_module import entry_point_target; entry_point_target()]` (these can be looked up in the project's metadata files or its package build configuration). This is the workaround for cases where there's no convenient `-m` compatible invocation published by the dependency. 4. Attempt to locate the wrapper scripts relative to `sys.path` entries, invoke it via `[sys.executable, path_to_wrapper_script]` once found. Not commonly used, since one of the above options will usually be easier. 5. Use `sysconfig` to manipulate `PATH` in the current process to ensure the environment's wrapper script folder is present. This is less reliable than the above options, since it still involves making potentially invalid assumptions about the expected relationship between `sys.path` and `PATH` configuration. It's fairly straightforward to make it work for the typical "everything in one venv" case, though. The first three options are the most reliable, but the last two do turn up sometimes (especially in code old enough to predate the existence of the `-m` switch). --- [Visit Topic](https://discuss.python.org/t/venv-activate-script-changes-path-while-executing-the-binary-doesnt/67580/11) or reply to this email to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.python.org/email/unsubscribe/c75bf907555584afd80f90d880ed107c933ba622f4ccd34d444e00da8e976dce).
