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:
- If a dependency offers a Python API, invoke it that way rather than via its CLI
- 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-mcompatible CLI invocation (there may not be a suitable module to execute that’s equivalent to running the wrapper script) - 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-mcompatible invocation published by the dependency. - Attempt to locate the wrapper scripts relative to
sys.pathentries, invoke it via[sys.executable, path_to_wrapper_script]once found. Not commonly used, since one of the above options will usually be easier. - Use
sysconfigto manipulatePATHin 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 betweensys.pathandPATHconfiguration. 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).