Closed jaraco closed 6 months ago
Can this be closed in favor of the pipx
approach in:
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 pipx uninstall nose2pytest
after they're done using it. In fact, it's still sitting around on my machine right now, even though I'm on a machine I bought in January, presumably because I transferred my pipx state from my old machine to this one.
In my case, I would have liked not to have to bothered with these concerns. pip-run
gives me stateless execution (install, run, and cleanup, all in one command). If it had supported pip-run, I would have saved time dealing with #28 by uninstalling for Python 3.12, learning the pipx invocation for installing to another python, and then installing it for Python 3.11. I would simply have replaced pip-run nose2pytest
with py -3.11 -m pip-run nose2pytest
with the rest of the command-line unchanged and been done. And then rather than leaving some install to linger in my user folder, if I ever go to run the command again, I'll get the latest release.
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. python -m pdb -m nose2pytest
). There are probably other use cases I'm not thinking about right now.
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 pipx run --python 3.11 nose2pytest@git+https://github.com/pytest-dev/nose2pytest
instead of pipx install --python 3.11 nose2pytest@git+https://github.com/pytest-dev/nose2pytest
in #30?
pipx run
should leave no cruft.
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.