Closed ajyoon closed 7 years ago
Hey there! Thanks for the PR, but I must admit I'm not sure I understand what it does. How is this better than what the command already does?
The purpose of this is to allow the actual code to reside in a .py
file, as is conventional.
I opened it because it took me more than a few seconds to find the code, as I was expecting it to be in a .py file. On other notes, it can confused certain text editors and workflows involving things like bash scripts where find . -type f -name *.py
are expecting python code.
Apologies for the confusing first commit -- I've reworked it now so that instead of using a stub launcher script, there is now an entry point in setup.py
allowing lptrace.py:main()
to be called from the command line via lptrace
. Please let me know if you prefer I rebase and force-push to a single commit to keep the history clean.
See, for example, the way pytest handles this: https://github.com/pytest-dev/pytest --- while obviously their needs are much more involved, they (and many other projects with pip-installable CLI interfaces) follow this same pattern.
Hey --- thanks for the explanation, it's much clearer now.
My main use case for running lptrace is using it for one-off debugging sessions. In this case, it's very handy to be able to run something like curl "https://raw.githubusercontent.com/khamidou/lptrace/master/lptrace" > lptrace && python lptrace -p ...
and have it work.
I'd really like to keep lptrace contained in a single file, which is why I'm going to close this pull request. Don't let this discourage you from contributing to open source, though --- your PR would be the right thing to do for most Python projects!
This somewhat trivial PR allows
lptrace
to be called from the command line while keeping the body of the code inlptrace.py
. It provides a small launcher script as the filelptrace
and moves the code to the.py
file. No other changes have been made.