[feature] Support pipx run with different name in entry point natively if a package wants to support it

[henryiii]

How would this feature be useful?

Currently, running pipx run build does not work; it requires pipx run --spec build pyproject-build. It would not be safe to add a build script entry point to pypa/build, due to how common that name would be. It would be nice to have a way for a package to tell pipx run "here's my entry point, use this". I know the author of pypa/build (@FFY00) was interested in supporting pipx (and pipx run build would be fantastic, imo). This affects projects with a common or unsafe name for an entry point.

Describe the solution you'd like
These are some initial ideas:

1. If a matching console entry point is not found, pipx run could fall back on python -m <name> if <name>/__main__.py is present.
2. There could be a pipx entry point in a package. Say "pipx.run.<name>". If this was specified, then that would be used by run. (I'm not very familiar with non-console entry points, but I think this is a valid way to use them)
3. Have a dict in pipx for common packages. (probably not a good idea? If Why is not pipx hosted under pypa github org? #596 went through, then one could argue that build, also being in the PyPA, would be a valid candidate for special treatment. This doesn't solve the issue generally, though)

These ideas would allow a package that supports pipx to have a dependency that supports pipx and not trip up the discovery.

Describe alternatives you've considered

This potentially would be a useful alternative to #177. I really like the idea of pipx run -m, as it would let me do things like pipx run -m rich, since rich so far has resisted adding an entry point and is python -m rich.<stuff> only.

[uranusjr]

The entry point usage would be appropriate, and I like it best among the proposed solutions.

[henryiii]

Great page on entry points: https://setuptools.readthedocs.io/en/latest/userguide/entry_point.html

So:

[options.entry_points]
pipx.run =
    build = build.__main__:entrypoint

For example? Any thoughts to implementation?

[uranusjr]

Implementation should be the simplest part. pipx already depends on importlib.metadata, which has an API for it. https://importlib-metadata.readthedocs.io/en/latest/using.html#entry-points

[uranusjr]

The most problematic issue to this approach would be to design a resolution logic both straightforward to explain and do what users expect most of the time in edge cases. One scenario from the top of my head are when a package defines both console_script and pipx.run entry points. Which should pipx choose? Should it offer an option to choose the other?

[henryiii]

Given that any package supporting this would be adding an explicit entrypoint for pipx, I think that should take precedence and there's no reason to offer options. I would expect it to be entirely used to allow packages to work with pipx that don't already have a matching Console entrypoint, but if someone did add a pipx.run entrypoint and a Console entrypoint with matching names, I would expect pipx to use the dedicated one. I would expect them to be the same, but maybe a package "X" provides two scripts, "A" and "X", but "A" is the main one and the one it wants to expose to pipx run. Or maybe a package can optimize something (like config lookup or something) if run through pipx.run. I really don't expect this to be used in this way, but just pointing out which one makes the most logical sense. It's probably already going to be hard enough to talk packages with unusual script names into adding the pipx.run entrypoint.

[uranusjr]

Makes sense. I may find some time to implement this and see how it works in practice.

[itsayellow]

I like the idea of a pipx entry point, and using pipx run to do this. Thanks for the suggestion @henryiii , this is a cleaner and imo better idea than past suggestions.

[uranusjr]

Draft implementation in #602.

[henryiii]

This is implemented and released in 0.16.1, I believe.

[henryiii]

@uranusjr are you making a PR to build, or should I?

[henryiii]

This was completed in #615 and released in 0.16, and is now even available on all the GitHub Actions runners! :)