-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support module __main__.py through python -m (entry points/console scripts) #1995
Comments
The behavior is largely documented in the runpy module. Setuptools supports this for its easy_install behavior as |
No, the original title is correct. I want entry points/console scripts that use -m behaviour. |
Can you give an example of what you're after? |
ideally something along the lines of:
but idk how the setup.py should look for it. |
I think I understand. So you want setuptools to accept a mapping of Note that the generated module would always be essentially boilerplate:
I'm a little wary of generating modules in a package. I'm also uneasy coupling I think I'd rather solicit a separate entry point for runpy indication:
This approach has the advantage of supplying the two similar features in a parallel way. The biggest disadvantage to this approach is that, similar to I wouldn't restrict the design to just package modules ( The main reason I'm wary to generate content is because it's not obvious when that content should be generated (should it appear in the sdist, in the built module, only at install time, is it optional?). Lots of design considerations. I'm more inclined to think that the package should simply supply the runpy script as part of the source, that the advantage of making it declarative is more trouble than than the value it provides. Can you elaborate on what problem you're trying to solve and what design you have in mind? |
nonono, no it should install in the PATH (or equivalent) the following script:
or equivalent. no |
this is for existing |
Was looking for a similar solution and stumbled upon this question.
And add at the end of
This ensures both In terms of integrating this in setuptools as a feature, the API could look like (my proposal):
The |
Interesting idea. Unfortunately, I don't think it's compatible with other syntaxes supported. I believe, for example, a dictionary is supported for the value for
Oh. That's interesting too. The biggest problem I see with that approach is it may not be compatible with executable wrappers like those used on Windows. It would still definitely require some support from pip (and other installers). |
Similar to @dbivolaru, I "solved" this by using:
i.e., Explicitly addressing the In the current system, you have to delimit module and the entrypoint callable with a colon. What if the logic was something like:
|
FWIW, after #2671 is resolved, this will have a universal cross build-backend answer -- putting something like the following in
|
This also has the side effect of messing up my __main__; because setuptools doesn't support __main__ modules, the entrypoints must refer to a function. Reference: pypa/setuptools#1995
Navigating packaging docs for first time as a novice package developer and Google brought me here and here. Both discussions seem to have stalled, sadly. This ...
just seems like an artifact from the days before |
+1. Adding a |
Hi @genevieve-me, thank you very much for the feedback. |
-m is a python standard (PEP 338) and we should support and encourage it. best way to do that is to defer to it when asked to. we should ideally also deprecate the old ways to further encourage -m usage.
The text was updated successfully, but these errors were encountered: