-
Notifications
You must be signed in to change notification settings - Fork 12
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 for runpy invocation #26
Comments
Can this be closed in favor of the |
The pipx approach leaves cruft on the user's system. The readme is silent on this concern and leaves nose2pytest lingering as an executable on the system or leaves it to the user to decide to In my case, I would have liked not to have to bothered with these concerns. Beyond pip-run, runpy invocation is valuable in environments where a script might not be available, such as an install to a user dir when the path hasn't been configured or because the executable was skipped during install. It's also valuable in debugging, as pdb supports runpy invocation (e.g. I don't disagree that pipx should be the recommended installation mode, but I feel strongly that any library with a CLI entry point should have a runpy invocation hook as well. |
What about recommending
|
I haven't used pipx run much, in part because it does still carry some cruft. It caches the virtualenvs, but at least it does expire them after some time. I'm unsure if or when it cleans them up. But you're right - that might be a good choice for this particular case I had. That still doesn't address the other benefits of supporting runpy invocation beyond pip-run. |
Today I needed nose2pytest for just long enough to run it once and I'll likely never need it again. In this case, it would have been nice to be able to invoke it without installing it permanently (thereby leaving cruft on my system). If the library had support for runpy invocation (e.g.
python -m nose2pytest
), I could have used pip-run to run it on demand without installing it anywhere permanently. To support this, the library would only need a__main__.py
in the package. I'd be happy to contribute it. Let me know.The text was updated successfully, but these errors were encountered: