镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Launchers for installed custom executable/scripts #401

Description

@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

Activity

  1. zooba commented on Aug 21, 2026

    @zooba
    Member

    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?

  2. segevfiner commented on Aug 21, 2026

    @segevfiner
    Author

    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.

  3. zooba commented on Aug 21, 2026

    @zooba
    Member

    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.

  4. segevfiner commented on Aug 21, 2026

    @segevfiner
    Author

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions