Description

segevfiner

opened on Aug 21, 2026

Issue body actions

Is your feature request related to a problem? Please describe.
Some packages install their own executables/scripts, for example https://pypi.org/project/ninja/, this won't get a launcher/shim when you run py install --refresh, leaving them inaccessible.

Describe the solution you'd like
Do create launchers/shims for those.

Describe alternatives you've considered
Install such things in an alternative way.

Additional context

Activity

1. segevfiner

   added

   enhancementNew feature or requestNew feature or request

   on Aug 21, 2026
2. zooba commented on Aug 21, 2026

   

   zooba

   on Aug 21, 2026

   Member

   More actions

   I don't see how that package is generating its own entry points... what would you propose as an alternative for detecting things that aren't following the specification?
3. segevfiner commented on Aug 21, 2026

   

   segevfiner

   on Aug 21, 2026

   Author

   More actions

   Exactly... I think it just drops a file into the classic scripts directory. Used to be fine when it was directly on the PATH, but now that it isn't, it might need to be modified to have the needed metadata for a launcher/shim to be created. But ehat metadata? It's an exe, not a Python script.
4. zooba commented on Aug 21, 2026

   

   zooba

   on Aug 21, 2026

   Member

   More actions

   We don't encourage using Python/PyPI packages as ways to distribute non-Python-based executables, so "it does it" isn't a compelling reason in itself. If you (or the maintainer? unclear if that's you) can provide a more compelling reason for why the package deserves a non-Python entrypoint to be associated with a specific Python runtime, that would help - right now I'm just completely ignorant of why it should even be done.

   The other thing to factor is "what if everyone does this?" or, more negatively, "what if people who hate us do this?" We don't want to promote someone's credential stealer to the top of PATH automatically and without auditing - at least when the entry point has to be a Python script, it's somewhat transparent to anyone scanning packages on the way in.

   Our launcher is also specific to launching Python, and has optimisations for that. Making it also launch arbitrary executables puts us in a position where we become responsible for a wide range of potential failures that we can't actually do anything about. So that risk has to be worth it.

   Otherwise, the workarounds would still be to add the specific environment's scripts to PATH, or for the package to use a different kind of install if it really doesn't fit into the standard model.
5. segevfiner commented on Aug 21, 2026

   

   segevfiner

   on Aug 21, 2026

   Author

   More actions

   Not the maintainer, I think its @bradking from Kitware, this package was/is mostly used for scikit-build/scikit-build-core as a means to have pio installs just work even if cmake and ninja are not already installed. Though I'm not sure how that mechanism works in scikit-build-core and if it still uses those packages.

   Reacted by Steve Dower

Issue actions