Ingots and artifacts
- Dominant language
- Rust
- Stars
- 1.7k
- Forks
- 218
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 9
Description
I'm thinking about ingots again. To give a concrete example, this is the current directory structure of the [bountiful code base after modularization](https://github.com/cburgdorf/bountiful/pull/1):
```
.
├── 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 `ILockValidator`pseudo 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.fe`were 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.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the proposed main.fe imports and the distinction between IngotMode::Lib and IngotMode::Main; review how the module hierarchy and contract artifacts are currently determined. Compare the workspace and fe.toml ideas, then define the accepted behavior for producing BountyRegistry, Game, and GameI8 artifacts from an IngotMode::Main ingot.
Written by the indexing model from the issue text.
Assessment
- Domain
- build-system, compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100