Validate config/manifest documents using Pydantic

[bschwedler]

• Use pydantic BaseModel for all Config objects
• Create ManifestDocument BaseModel and add validation

First step in #51

[github-actions]

Test Results

135 tests   133 ✅  5s ⏱️
  1 suites    2 💤
  1 files      0 ❌

Results for commit f8a1582.

♻️ This comment has been updated with latest results.

[bschwedler]

@ianpittwood I fully expect that further validations and test will be required when I start to convert the document objects into the targetbuild/project structure.

[ianpittwood]

We should probably consider updating the version in pyproject.toml at least to a new dev version.

Everything looks good so far direction-wise to me! I mostly had questions and some nits on typos and such.

[ianpittwood]

For my own understanding, would we be receiving the substring of the Containerfile extension in here? For example (and I know these have been altered) from our existing files ubuntu2204 or centos7

[bschwedler]

I haven't gotten to that point yet. I was intending to look at this when I re-worked how the manifests relate to the build plan.

[ianpittwood]

nit: I prefer globals/constants to always be just after imports or for them to be members of their relevant class. I can also understand why grouping them may be more visible for you though. Perhaps we should consider further breaking down these definitions into additional files and/or modules and utilizing __init__.py to export them for ease of use?

[bschwedler]

I originally had these up at the top of the file. I'll move them back up there.

I like your idea of adding more files. I'll think about how to do this, but now I'm thinking separate modules for the config/manifest and making each file much smaller.

[ianpittwood]

I was thinking maybe something like this:

.
└── models/
    ├── __init__.py
    ├── config/
    │   ├── __init__.py
    │   ├── components.py
    │   │   ├── <ConfigRegistry>
    │   │   └── <ConfigRepository>
    │   ├── document.py
    │   │   └── <ConfigDocument>
    │   └── model.py
    │       └── <Config>
    └── manifest/
        ├── __init__.py
        ├── components.py
        │   ├── <BuildOS>
        │   └── <GossConfig>
        ├── document.py
        │   ├── <ManifestGoss>
        │   ├── <ManifestBuild>
        │   ├── <ManifestTarget>
        │   └── <ManifestDocument>
        └── model.py
            ├── <TargetBuild>
            └── <Manifest>

But that's just an idea for splitting stuff up in a pattern between the two primary definition types.

I do think this draws attention to a possible issue, however. We may need to make the delineation clearer between classes used for ingesting the Document versus those used for modeling the related Object. I don't think classes like ConfigRegistry or ConfigRepository should necessarily be reused and instead should have ConfigDocumentX classes. I think we want to still clearly separate Document=Validation and Model=Transformation.

[bschwedler]

This has been refactored in the latest commits.

I completely agree with keeping the config and manifest document information separate from the usage. In the next PR, I'll be refactoring the Project class and related thingz and we'll see where everything lands.

[bschwedler]

@ianpittwood Can you please give this another once-over? Thanks!

[ianpittwood]

Just a few issues in os.py mainly and some other suggestions. I think it'll be good once the missed variable renames get fixed :D.

[ianpittwood]

Same as os.py, perhaps this should be target_goss.py?

[bschwedler]

I'm going to leave this one as goss.py since the TargetGoss will come in the next PR.