Election-Tech-Initiative / Election-Tech-Initiative/electionguard-python

🧱 Improve monorepo structure of projects

Open
#647 1 comment 0 reactions 0 assignees View on GitHub
code owner only enhancement
Dominant language
Python
Stars
168
Forks
103
PR merge metrics
No merged PRs in 30d

Description

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Suggestion

The existing structure of the repository has a focus on exporting the ElectionGuard Core which is present in the `src/electionguard` file path. Gradually, more has been added but there has been a lack of distinction between the sections. Here is a full description of each section:

`electionguard` : The core python electionguard
`electionguard_tools`: An addendum to the core to add hypothesis strategies for tests, factories for building elections, and support tools to improve tests.
`electionguard_cli`: CLI for performing developer methods
`electionguard_verifier`: A simplified example of a verifier. Doesn't not include all verification checks.
`electionguard_gui`: _under construction_ A GUI implementation of administrative and guardian device.

Currently, we have one pyproject.toml defining the entire project. This results in one virtual environment.

### Possible Implementation

An ideal scenario is to isolate the core as a library from the applications. This would help clarify what needs to be tested as well. This is a prime example including versions of how the code works.
https://github.com/dermidgen/python-monorepo

My proposal is to mimic the previous setup with some minor changes.

```md
libs/
electionguard/
core/ # formerly electionguard (this should align with any future ElectionGuard API spec)
extras/ # formerly electionguard_tools (this is for extras to improve upon core experience)
tests/
....
pyproject.toml
tools/ # or apps/
verifier/ # formerly electionguard_verifier
....
pyproject.toml
cli/ # formerly electionguard_cli
....
pyproject.toml
admin/
....
pyproject.toml
```

### Anything else?

Ensure you understand the `develop` option in poetry.
https://python-poetry.org/docs/dependency-specification/#path-dependencies

These will likely make the `make` commands more pivotal. For example `make lint` will have to lint all the different project folders. Some existing commands should be shifted into the pyproject.toml similar to package.json with scripts.
This may be a good option for this. https://pypi.org/project/poethepoet/

There will be changes to packaging and imports. However, the only difference will be the `electionguard` package will have a different route.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.