Closed Dustin-Ray closed 5 months ago
The advantages of this arent readily apparent until we add functionality outside of core capycrypt, i.e. zero-knowledge proving mechanisms, GUI, or CLI. An example of how this should look, using workspaces, is as follows:
capycrypt/ │ ├── Cargo.toml # Workspace configuration ├── README.md ├── .gitignore │ ├── src/ # Source files for the main binary (if any) │ ├── main.rs │ └── lib.rs │ ├── capycrypt/ # Example library crate │ ├── Cargo.toml # Library crate configuration │ ├── src/ │ │ ├── lib.rs │ │ ├── module1.rs │ │ └── module2.rs │ └── tests/ │ └── lib_tests.rs │ ├── capycrypt-cli/ # Example binary crate │ ├── Cargo.toml # Binary crate configuration │ ├── src/ │ │ └── main.rs │ └── tests/ │ └── bin_tests.rs │ ├── capycrypt-gui/ # Another example library crate │ ├── Cargo.toml │ └── src/ │ └── lib.rs │ └── tests/ # Integration tests for the entire workspace └── integration_test.rs
Then, in the Cargo.toml at the head of the project, we include all of the members:
[workspace]
members = [
"capycrypt",
"capycrypt-cli",
"capycrypt-gui"
]
this is needed somewhat more urgently now in order to bring the curve back in, which will resolve #40.
current design works well enough, but to support maintainability and future enhancements, the file structure should be refactored to make better use of idiomatic rust directory layout.