Developer Information

Type Annotations

Python type annotations / hints for the base Libcloud compute API have been added in v2.8.0.

The goal behind type annotations is to make developer lives easier by introducing optional static typing for Python programs.

This allows you to catch bugs and issues which are related to variable types earlier and faster (aka when you run mypy locally either manually or integrated in your editor / IDE and also as part of you CI/CD build pipeline).

An example of how to use type annotations correctly is shown below.

  1. # Licensed to the Apache Software Foundation (ASF) under one or more
  2. # contributor license agreements. See the NOTICE file distributed with
  3. # this work for additional information regarding copyright ownership.
  4. # The ASF licenses this file to You under the Apache License, Version 2.0
  5. # (the "License"); you may not use this file except in compliance with
  6. # the License. You may obtain a copy of the License at
  7. #
  8. # http://www.apache.org/licenses/LICENSE-2.0
  9. #
  10. # Unless required by applicable law or agreed to in writing, software
  11. # distributed under the License is distributed on an "AS IS" BASIS,
  12. # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  13. # See the License for the specific language governing permissions and
  14. # limitations under the License.
  15. from libcloud.compute.types import Provider
  16. from libcloud.compute.providers import get_driver
  17. from libcloud.compute.drivers.ec2 import EC2NodeDriver
  18. from libcloud.compute.drivers.rackspace import RackspaceNodeDriver
  19. from typing import Type, cast
  20. ec2_cls = get_driver(Provider.EC2)
  21. rackspace_cls = get_driver(Provider.RACKSPACE)
  22. # NOTE: If you are using driver methods which are not part of the standard API,
  23. # you need to explicitly cast the driver class reference to the correct class
  24. # for type checking to work correctly
  25. EC2 = cast(Type[EC2NodeDriver], ec2_cls)
  26. Rackspace = cast(Type[RackspaceNodeDriver], rackspace_cls)
  27. drivers = [EC2('access key id', 'secret key', region='us-east-1'),
  28. Rackspace('username', 'api key', region='iad')]
  29. nodes = []
  30. for driver in drivers:
  31. nodes.extend(driver.list_nodes())
  32. print(nodes)
  33. # [ <Node: provider=Amazon, status=RUNNING, name=bob, ip=1.2.3.4.5>,
  34. # <Node: provider=Rackspace, status=REBOOT, name=korine, ip=6.7.8.9.10>, ... ]
  35. # grab the node named "test"
  36. node = [n for n in nodes if n.name == 'test'][0]
  37. # reboot "test"
  38. node.reboot()

If you reference an invalid object attribute or a method, you would see an error similar to the one beloe when running mypy:

  1. ...
  2. print(nodes[0].name)
  3. print(nodes[0].invalid)
  4. print(nodes[0].rebbot())
  5. print(nodes[0].reboot(foo='invalid'))
  6. ...
  1. $ mypy --no-incremental example_compute.py
  2. example_compute.py:41: error: "Node" has no attribute "invalid"
  3. example_compute.py:42: error: "Node" has no attribute "rebbot"; maybe "reboot"?
  4. example_compute.py:43: error: Unexpected keyword argument "foo" for "reboot" of "Node"

If you are using driver methods which are not part of the Libcloud standard API, you need to use cast() method as shown below to cast the driver class to the correct type. If you don’t do that, mypy will only be aware of the methods which are part of the Libcloud base compute API (aka BaseNodeDriver class).

This is needed because of how Libcloud utilizes meta programming for the get_driver() and related methods (there is no other way without writing a mypy plugin to achieve that).

Mailing Lists

All of the communication about Libcloud development happens on our mailing lists.

Archive of old incubator mailing lists:

IRC

  • libcloud on Freenode

Issue Tracker

For bug and issue tracking we use Github issues located at https://github.com/apache/libcloud/issues.

Testing

For information how to run the tests and how to generate the test coverage report, please see the Testing page.

Continuous Integration

For continuous integration we use Travis-CI. You can find build reports on the following links:

Travis-CI builder is also integrated with Github which means that if you open a pull request there, Travis-CI will automatically build it.

If you want to validate the build before raising the PR, Travis-CI can be enabled for personal accounts and branches separately.

Test Coverage

Test coverage report is automatically generated after every push and can be found at https://codecov.io/github/apache/libcloud?branch=trunk.