-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
HackIllinois 2019
Thank you for participating in this setuptools sprint event. In addition to the issues on the issue tracker (which have been organized by labels), other general improvements - particularly to the documentation, build and test - would be very useful.
- Project board: https://github.com/orgs/pypa/projects/2
- Contributor's Guide for Setuptools
- A short presentation from the 2018 PyPA Sprint - This has useful information about using git and finding issues
- A recent three-part series on Python packaging by Bernat Gabor - This is very thorough and should get you a sense of where packaging is and where it's going
- Creating a commit with multiple authors
- good first issue - These are small, well-scoped issues that would be good for a first time contributor
- Needs Implementation - These are issues where it is already known what needs to be done and it just needs to be implemented.
- help wanted - All issues where we are looking for help.
There are a few issues that would be great to get done, and are pretty meaty:
- Document all supported keywords (#1700) - This is a pretty major refactoring of the documentation, you may want to work on a team for this.
- Add mechanism for side-by-side comparison of setup.py and its equivalent setup.cfg (#1699) - Another fairly major undertaking
- Add mechanism to update vendored dependencies automatically (#1696)
We also welcome other general improvements for which there is no specific issue. The biggest "unstructured" improvements to be made are around test coverage and documentation.
The easiest thing to do to improve the testing is adding more tests to get our coverage to 100%. This can be done by navigating through the codecov coverage report and finding lines untouched by the current test suite. It is acceptable to use # pragma: nocover sparingly, for things where it is more trouble than it's worth to test them. If in doubt about when to do this, please ask.
The biggest principle of adding tests is only test the public interface! That means that you should never use a private function / method / attribute in a test - private functions and methods are those that do not appear in the module's __all__ (if it has one), or those starting with an underscore. Hit these functions by calling the functions that call them instead.
The documentation for setuptools is in very rough shape. It is super out of date in many ways. There are many issues tagged documentation that you can take on. Some of which, like #1700, are indeed very meaty.
Another possible workflow for finding issues with the setuptools documentation is to navigate to the documentation and try to get a sense for what the module does, what it is capable of and how it works. If you are confused or find it hard to navigate, take note of this and see if it can be improved.
You can also try reading through the source code and, if you are confused about how you would use one of the features you find there, try to find it in the documentation. Note anything missing.