Contributions are welcome and appreciated! Every little bit helps, and a credit will always be given.
If you are new to ScanCode and want to find easy tickets to work on, check easy issues
When contributing to ScanCode (such as code, bugs, documentation, etc.) you agree to the Developer Certificate of Origin and the ScanCode license (see the NOTICE file). The same approach is used by Linux Kernel developers and several other projects.
For commits, it is best to simply add a line like this to your commit message, with your name and email:
Signed-off-by: Jane Doe <[email protected]>
Please try to write a good commit message, see good commit message wiki for details. In particular use the imperative for your commit subject: think that you are giving an order to the codebase to update itself.
To send feedback or ask a question, file an issue
If you are proposing a feature:
- Explain how it would work.
- Keep the scope as simple as possible to make it easier to implement.
- Remember that your contributions are welcomed to implement this feature!
For other questions, discussions, and chats, we have:
- an official Gitter channel at https://gitter.im/aboutcode-org/discuss Gitter also has an IRC bridge at https://irc.gitter.im/ This is the main place where we chat and meet.
- an official #aboutcode IRC channel on liberachat (server web.libera.chat) for scancode and other related tools. You can use your favorite IRC client or use the web chat at https://web.libera.chat/?#aboutcode . This is a busy place with a lot of CI and commit notifications that makes actual chat sometimes difficult!
- a Gitter channel to discuss Documentation at https://gitter.im/aboutcode-org/gsod-season-of-docs
When reporting a bug please include:
- Your operating system name, version, and architecture (32 or 64 bits).
- Your Python version.
- Your ScanCode version.
- Any additional details about your local setup that might be helpful to diagnose this bug.
- Detailed steps to reproduce the bug, such as the commands you ran and a link to the code you are scanning.
- The error messages or failure trace if any.
- If helpful, you can add a screenshot as an issue attachment when relevant or some extra file as a link to a Gist.
Documentation can come in the form of new documentation pages/sections, tutorials/how-to documents, any other general upgrades, etc. Even a minor typo fix is welcomed.
If something is missing in the documentation or if you found some part confusing, please file an issue with your suggestions for improvement. Use the “Documentation Improvement” template. Your help and contribution make ScanCode docs better, we love hearing from you!
The ScanCode documentation is hosted at scancode-toolkit.readthedocs.io.
If you want to contribute to Scancode Documentation, you'll find this guide here helpful.
To set up ScanCode for local development:
Fork the scancode-toolkit on GitHub, click fork button
Clone your fork locally:
Use SSH:
git clone [email protected]:your_name_here/scancode-toolkit.git
Or use HTTPS:
git clone https://github.com/your_name_here/scancode-toolkit.git
See also GitHub docs for SSH or HTTPS
If you want to change the connection type, do following
SSH to HTTPS
git remote set-url <repository-alias-name> https://github.com/your_name_here/scancode-toolkit.git
HTTPS to SSH
git remote set-url <repository-alias-name> [email protected]:your_name_here/scancode-toolkit.git
Generally <repository-alias-name> is named origin, but in the case of multiple fetch/pull source of repository you can choose whatever name you want
Create a branch for local development:
git checkout -b name-of-your-bugfix-or-feature
Check out the Contributing to Code Development documentation, as it contains more in-depth guide for contributing code and documentation.
To configure your local environment for development, locate to the main directory of the local repository, and run the configure script. The configure script creates an isolated Python virtual environment in your checkout directory, the Python pip tool, and installs the third-party libraries (from the thirdparty/ directory), setup the paths, etc. See https://virtualenv.pypa.io/en/latest/ for more details.
Run this command to configure ScanCode:
./configure --dev
On Windows use instead:
configure --dev
Then activate the virtual environment:
source venv/bin/activate or . venv/bin/activate
On Windows use:
venv\Scripts\activate
When you create a new terminal/shell to work on ScanCode rerun the activate step.
When you pull new code from git, rerun ./configure
Now you can make your code changes in your local clone. Please create new unit tests for your code. We love tests!
An update to the
CHANGELOGis required if any important changes are made that needs to be communicated such as:- Changes in the API.
- Addition or deletion of CLI options.
- Addition of any new feature or any other miscellaneous changes to the program.
If there is a code change, a significant document, or any other changes, you must update the
AUTHORSto include your own name.When you are done with your changes, run all the tests. Use this command:
py.test
Or use the -n6 option to run on 6 threads in parallel and run tests faster:
py.test -n6
If you are running this on a RedHat-based OS you may come across this failure:
OSError: libbz2.so.1.0: cannot open shared object file: No such file or directory
Try creating a symbolic link to libbz2.so.1.0 to solve this issue:
locate libbz2.so.1.0 cd <resulting libbz2.so directory> sudo ln -s <your version of libbz2.so> libbz2.so.1.0
See this issue for more information.
Check the status of your local repository before committing, regarding files changed:
git status
Commit your changes and push your branch to your GitHub fork:
git add <file-changed-1> <file-changed-2> <file-changed-3> git commit -m "Your detailed description of your changes." --signoff git push <repository-alias-name> name-of-your-bugfix-or-feature
Submit a pull request through the GitHub website for this branch.
If you need a code review or feedback while you are developing the code just create a pull request. You can add new commits to your branch as needed.
For merging, your request would need to:
- Include unit tests that are passing (run
py.test). - Update documentation as needed for new API, functionality, etc.
- Add a note to
CHANGELOG.rstabout the changes. - Add your name to
AUTHORS.rst.
To run a subset of test functions containing test_myfeature in their name use:
py.test -k test_myfeature
To run the tests from a single test file:
py.test tests/commoncode/test_fileutils.py
To run tests in parallel on eight processors:
py.test -n 8
To run tests verbosely, displaying all print statements to terminal:
py.test -vvs