XlsxWriter: Bug Reports and Pull Requests
Here are some tips on reporting bugs in XlsxWriter.
Upgrade to the latest version of the module
The bug you are reporting may already be fixed in the latest version of the module. You can check which version of xlsxwriter that you are using as follows:
python -c 'import xlsxwriter; print(xlsxwriter.__version__)'
The Changes file lists what has changed in the latest versions.
Read the documentation
Read or search the XlsxWriter documentation to see if the issue you are encountering is already explained.
Look at the example programs
There are many example programs in the distribution. Try to identify an example program that corresponds to your query and adapt it to use as a bug report.
Pointers for submitting a bug report
- Describe the problem as clearly and as concisely as possible.
- Include a sample program. This is probably the most important step. It is generally easier to describe a problem in code than in written prose.
- The sample program should be as small as possible to demonstrate the problem. Don't copy and paste large non-relevant sections of your program.
Sample Bug Report
A sample bug report is shown below. This format helps to analyze and respond to the bug report more quickly.
Issue with SOMETHING
I am using XlsxWriter to do SOMETHING but it appears to do SOMETHING ELSE.
I am using Python version X.Y.Z and XlsxWriter x.y.z.
Here is some code that demonstrates the problem::
import xlsxwriter workbook = xlsxwriter.Workbook('hello.xlsx') worksheet = workbook.add_worksheet() worksheet.write('A1', 'Hello world') workbook.close()
See also how How to create a Minimal, Complete, and Verifiable example from StackOverflow.
Use the XlsxWriter GitHub issue tracker
Submit the bug report using the XlsxWriter issue tracker.
Pull Requests and Contributing to XlsxWriter
All patches and pull requests are welcome but must start with an issue tracker.
- Pull requests and new feature proposals must start with an issue tracker. This serves as the focal point for the design discussion.
- Describe what you plan to do. If there are API changes or additions add some pseudo-code to demonstrate them.
- Fork the repository.
- Run all the tests to make sure the current code work on your system using
- Create a feature branch for your new feature.
- Enable Travis CI on your fork, see below.
Enabling Travis CI via your GitHub account
Travis CI is a free Continuous Integration service that will test any code you push to GitHub with various versions of Python 2 and 3, and PyPy.
See the Travis CI Getting Started instructions.
Note there is already a
.travis.yml file in the XlsxWriter repo so that doesn't need to be created.
This is the most important step. XlsxWriter has over 1000 tests and a 2:1 test to code ratio. Patches and pull requests for anything other than minor fixes or typos will not be merged without tests.
Use the existing tests in
XlsxWriter/xlsxwriter/test/ as examples.
Ideally, new features should be accompanied by tests that compare XlsxWriter output against actual Excel 2007 files. See the
XlsxWriter/xlsxwriter/test/comparison test files for examples. If you don't have access to Excel 2007 I can help you create input files for test cases.
Tests should use the standard unittest Python module.
Follow the general style of the surrounding code and format it to the PEP8 coding standards.
Tests should conform to
PEP8 but can ignore
E501 for long lines to allow the inclusion of Excel XML in tests.
There is a make target that will verify the source and test files:
As a minimum, tests should be run using Python 2.7 and Python 3.5.
make test # or py.test
When you push your changes they will also be tested using Travis CI as explained above.
The docs, in
dev/docs/source can be built in Html format using:
If applicable add an example program to the
Copyright and License
Copyright remains with the original author. Do not include additional copyright claims or Licensing requirements. GitHub and the
git repository will record your contribution an it will be acknowledged in the Changes file.
Submitting the Pull Request
If your change involves several incremental
git commits then
squash them onto another branch so that the Pull Request is a single commit or a small number of logical commits.
Push your changes to GitHub and submit the Pull Request with a hash link to the to the Issue tracker that was opened above.