pywincffi 0.5.0

Function Documentation

Windows API Functions are typically documented in the following format:

def DuplicateHandle(arg1, kwarg1=None):
    """
    A brief message about this function.

    .. seealso::

        <url to the MSDN API documentation for this function>

    :param type arg1:
        Brief information about this argument

    :keyword type kwarg1:
        Brief information about this keyword include it's default
        and how it's handled within the function.

    :raises SomeException:
        Some information on when this exception will be raised

    :rtype: type
    :return:
        Information about the data that's returned
    """

It’s important to note that the docs contain a seealso stanza. This is typically used to reference the MSDN documentation but may also be used to reference examples, white papers or other reference which may be useful in describing the function.

Adding new functions is covered in greater detail here

Continuous Integration

To consistently ensure the highest quality code, the following services are utilized to test or analyze every commit and pull request:

• AppVeyor - Runs the unittests, builds wheel files, MSIs and other output artifacts which can be published in a release.

• Travis - Runs the pep8 and pylint command line tools on the code base and tests. This also builds the docs so documentation problems are easily spotted.

• Codecov - Analyses and displays code coverage results after tests have run on AppVeyor. Results are posted back to pull requests.

• ReadTheDocs. - The official location where documentation is built and posted. This is generally for merges into the master branch however.

Additional Testing

As seen above, there are numerous tests besides the unittests. To run all the tests on Windows, much like the continuous integration systems do, you can run test.bat:

> check.bat

This will:

• Check code style for both the library and tests.

• Run all unittests.

• Build the wheel file.

• Build the documentation and treat warnings as errors.

Keep in mind that this will not setup the virtualenv or build environment for you. So if you can’t build the library or are missing a dependency then the above may fail.

Vagrant

The continuous integration services above negate most of the need to setup your local workstation to handle development for pywincffi, even if you’re not running Windows. In some cases however it can be faster or easiear to work on your local machine.

If you’re not running Windows or you don’t have the tools necessary to develop pywincffi on your machine you can use Vagrant to build a Windows machine and start developing. There’s a more in depth explanation of this process located here:

https://pywincffi.readthedocs.org/en/latest/dev/vagrant.html