Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Online crash reporting. See #1853 #2313
Most of the error reporting is now in quodlibet.errorreport
Depends on raven, which is unlikely to be installed atm, maybe we'll vendor it.
This now includes raven and contextlib2 directly in git and will also install it. They both don't get included in the source tarball and the code falls back to prefilled gihub issues in those cases. Couldn't think of anything better..
raven required quite a bit of monkey patching to get working for our use case, but since we only use the internal version this should be fine I guess.
I consider this mergeable, feedback welcome.
Good work! All seems to function properly here, though I haven't got the Sentry login to check anything on the other side.
The bit that scares me slightly is the diff:
Alternatively is an egg / wheel in Git an option - then there's a cleaner distinction between vendor code and QL code (and devs / IDEs don't see that code so much)? I guess it would still need an explicit build step which is a bit weird for Python (maybe...).
Thanks. I'll look into making it possible for more people to see the data.
Build step would work somehow. The upside now is that we can test it on travis.
I haven't checked, but zip import might work. Is there any problem with your IDE and the current solution?
See bebd0ef for the code needed to mark quodlibet.optpackages as "not part of the project".
All in all I'm open to rework this in the future if an alternative arises.
Zip import sounds good. No problems as such, more just being in the source tree it gets treated like real source code, e.g. notifying of code problems (>1000 warnings there). I suppose we can just configure IDEs to also ignore that folder tree.
BTW do we need any of
OK so maybe let's get it in now and think of something to do with build steps / zip imports separately...