Launchers for installed custom executable/scripts

[segevfiner]

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

[zooba]

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?

[segevfiner]

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.

[zooba]

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.

[segevfiner]

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.