Ready to contribute? Here’s how to set up fedora_infra_map for local development.
1. Fork the fedora_infra_map repo on GitHub.
2. Clone your fork locally:
$ git clone [email protected]:your_name_here/fedora-infra-map.git
3. Install your local copy into a virtualenv. Assuming you have virtualenvwrapper installed, this is how you set up your fork for local development:
$ mkvirtualenv fedora_infra_map
$ cd fedora_infra_map/
$ python setup.py develop
4. Create a branch for local development:
$ git checkout -b name-of-your-bugfix-or-feature
Now you can make your changes locally.
5. When you’re done making changes, check that your changes pass flake8 and the tests, including testing other Python versions with tox:
$ flake8 fedora_infra_map tests
$ python setup.py test or pytest
$ tox
To get flake8 and tox, just pip install them into your virtualenv.
6. Commit your changes and push your branch to GitHub:
$ git add .
$ git commit -m "Your detailed description of your changes."
$ git push origin name-of-your-bugfix-or-feature
7. Submit a pull request through the GitHub website.
8 Chapter 4. Contributing
2. If the pull request adds functionality, the docs should be updated. Put your new functionality into a function with a docstring, and add the feature to the list in README.rst.
3. The pull request should work for Python 3.7 and 3.8, and for PyPy. Checkhttps://travis-ci.org/github/Zlopez/
fedora-infra-map/pull_requestsand make sure that the tests pass for all supported Python versions.
4.4 Tips
To run a subset of tests:
$ pytest tests.test_fedora_infra_map
4.5 Deploying
A reminder for the maintainers on how to deploy. Make sure all your changes are committed (including an entry in HISTORY.rst). Then run:
$ bump2version patch # possible: major / minor / patch
$ git push
$ git push --tags
Travis will then deploy to PyPI if tests pass.
fedora-infra-map Documentation, Release 0.1.0
10 Chapter 4. Contributing
Credits
5.1 Development Lead
• Michal Koneˇcný <[email protected]>
5.2 Contributors
None yet. Why not be the first?
fedora-infra-map Documentation, Release 0.1.0
12 Chapter 5. Credits
History
6.1 0.1.0 (2020-03-27)
• First release on PyPI.
fedora-infra-map Documentation, Release 0.1.0
14 Chapter 6. History
Fedora Infra Map requirements
This is the list of requirements for fedora-infra-map app.
7.1 List of requirements
• Interactive web interface
• Map of the fedora infra represented by nodes and edges
• Querying of the specific nodes, edges by attributes
• Node represents app itself (name, description, ownership, url)
• Edge represents relationship between apps (type, description)
fedora-infra-map Documentation, Release 0.1.0
16 Chapter 7. Fedora Infra Map requirements
Fedora Infra Map app design
Fedora Infra Map is using clean architecture design and directories structure based on the requirements. Clean archi-tecture was chosen to allow Fedora Infra Map parts to be easily replaceable and easily maintainable.
The design will be split to three parts relevant to three layers Entities, Use Cases and External systems.
8.1 Entities
Inner definitions of objects we will work with and their serializers. This is the core of the whole application. Bellow is the directory structure.
Internal representation of node in the map. One node = one app.
8.1.2 edge.py
Internal representation of edge in the map. One edge = one relationship between two apps.
fedora-infra-map Documentation, Release 0.1.0
8.1.3 node_json_serializer
JSON serializer for node object. This allows us to use json.dumps on the Node object.
8.1.4 edge_json_serializer
JSON serializer for edge object. This allows us to use json.dumps on the Edge object.
8.2 Use cases
Use cases corresponds to requirements. This layer will define what the application can do. Bellow is the directory structure for this layer. This layer also contains abstract classes which will be inherited by external systems and response/requests definition with any exceptions.
fedora_infra_map
This class returns the list of nodes and list of edges connecting them or error. It calls abstract Database class, request a query and handle response from external system.
8.2.2 node_edge_list_request
Request passed to node_edge_list it contains a list of filters to apply.
8.2.3 response
Abstract class which is inherited by other responses. This class also defines constants for any response code. Defines __bool__method.
8.2.4 response_success
This class is inherited from Response and is returned when use case finishes successfully. Implements __bool__
method that returns True and value attribute, which contains return value from use case if any.
18 Chapter 8. Fedora Infra Map app design
8.2.6 database
Abstract class that defines the API for database. It needs to be inherited by any external database class.
8.3 External systems
This is the outer layer of clean architecture and contains wrappers that are calling external systems and any helper class used by the wrappers. Wrappers will inherit abstract class defined in use cases layer.
fedora_infra_map +-- database
+-- csv.py +-- config.py
8.3.1 csv
This class implements database wrapper around CSV files.
8.3.2 config
This class is centralized implementation of application configuration.
fedora-infra-map Documentation, Release 0.1.0
20 Chapter 8. Fedora Infra Map app design
Indices and tables
• genindex
• modindex
• search