Ingots and artifacts

[cburgdorf]

I'm thinking about ingots again. To give a concrete example, this is the current directory structure of the bountiful code base after modularization:

.
├── challenges
│   ├── errors.fe
│   ├── game.fe
│   └── game_i8.fe
├── main.fe
└── registry
    ├── errors.fe
    ├── lock_validator.fe
    ├── registry.fe
    └── solvable.fe

As far as deployments go there is the BountyRegistry in registry.fe and then there are the different code challenges in challenges. These things are fairly decoupled. E.g. the registry doesn't have to know the challenges and the challenges don't have to know the registry (apart from using the ILockValidatorpseudo interface).

Yet, for testing and deployment I want three contracts to be deployed BountyRegistry, Game and GameI8. If this was a Rust project then I believe we would use a workspace and each game would become its own bin crate, the registry would become its own bin crate and there were several lib crates to share some logic and interfaces (e.g. ILockvalidator, ISolvable etc).

Since we do not have workspaces (yet) this is just a single project with a main.fe but we still somehow need to get the artifacts for our three contracts. In the last meeting we said that maybe we want a fe.toml do decide which contracts to include. I'm trying to think that through. In the concrete example, we would still need the main.fe to use all our three contracts and look like this, right?

use registry::registry::BountyRegistry
use challenges::game::{Game, GameI8}

We wouldn't just allow the main.fe file to be empty and have the fe.toml take full control, right? Because if the main.fewere allowed to be empty then we would have no root to tell us which files should even be included for compilation. It would also mean that the distiction between IngotMode::Lib and IngotMode::Main would become less clear if at the end of the day the fe.toml decides what is or is not going to be compiled.

So, to me it seems that:

1. Long term, we would want workspaces and then a project such as bountiful might choose a structure like described above

If this was a Rust project then I believe we would use a workspace and each game would become its own bin crate, the registry would become its own bin crate and there were several lib crates to share some logic and interfaces (e.g. ILockvalidator, ISolvable etc).

2. In the meantime we always want to produce all artifacts for all contracts that were compiled for an IngotMode::Main ingot. That means all contracts that exists in the module hierarchy that starts at the main.fe. To be clear, not only the contracts that are defined within the main.fe but all the contracts that are analyzed as part of the ingot.

[sbillig]

We wouldn't just allow the main.fe file to be empty and have the fe.toml take full control, right? Because if the main.fewere allowed to be empty then we would have no root to tell us which files should even be included for compilation. It would also mean that the distiction between IngotMode::Lib and IngotMode::Main would become less clear if at the end of the day the fe.toml decides what is or is not going to be compiled.

I was thinking we'd get rid of the concept of a "main" file. There would be no single root. Instead, the contracts that are specified in fe.toml would all be compiled for deployment (and would thus be roots of their own code inclusion tree).

Maybe it makes sense to just compile every contract in the project, like you suggest. I think complex cases might justify having the contracts to be compiled specified in fe.toml. For example, if the project includes an external ingot that defines a contract; you may just want to use the type of that contract locally, and not compile a copy. Or you might want to compile and deploy a copy of that external contract at a new address.