-
-
Notifications
You must be signed in to change notification settings - Fork 933
Prints to stderr from library #33
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
Comments
Thanks for bringing this up. The code you mentioned is rather old and serves more for debugging purposes, as to indicate that something wrong happened at least. I would prefer to keep some sort of message, but it should be configurable by the user of the library. Would you think that using python logging instead would be a viable option ? If so, the few occurrences of printing directly to stderr could easily be fixed. |
Sure, python logging would be appropriate. If the calling code wishes to get debug info they can hook into the logger. By default the GitPython library can use a null handler, but still make appropriate log.info and log.error calls. Any self testing code could hook into the logger and provide appropriate logging targets. FWIW, that's exactly how I handle it in some of my libraries. The library null logs, client code adds handlers to pick up on library logging output. Client can decide quiet, info, verbosity. |
Python logging will be used consistently in 0.3.4 when making it ready for py3. |
Python logging is used in 0.3.3 already, which is now online on pypi too. |
git/objects/commit.py has a few places where it will print to stderr if unable to decode a stream from the repo. This has ill effect on client callers to the library. In my case, I'm making use of GitPython in a git update hook, and this stderr print is making its way back to the user's console and confusing them when they push.
Can we make these prints optional?
The text was updated successfully, but these errors were encountered: