feat: ✨ add Layout chapter for structure of package

[lwjohnst86]

Description

This lists all the files and folders within a data package, as a high-level overview of a data package but also of the book itself.

The PR is a bit on the long side, but I thought it was ok because it isn't high priority to review and merge in.

Needs a thorough review.

Checklist

• Ran just run-all

[signekb]

Very nice overview 🌟 When reading, I thought that I might as well give some suggestions:

[signekb]

I guess this should also have been a separate PR

[signekb]

Same with these changes. Could have been in a separate PR.

[signekb]

Very nice overview 🌟 When reading, I thought that I might as well give some suggestions:

[joelostblom]

Looks good! Just some minor comments

[joelostblom]

Would it be helpful to include a short motivation as to why?

[joelostblom]

For pretty display of file trees, could we reuse the same code from soil that we used in flower and sprout?

[joelostblom]

Do you think it would be beneficial to give our more general data package another name that is less similar to the existing Data Package standard? "Package" is maybe the nicest name, and we could make a technical point around the use of title case or not, but it will likely still be confusing to try to distinguish the two, even more so in speech. Calling it "data package" also makes it sound like we're closer to the datapackage.json standard than e.g. data-dict.yaml or anything else that would be developed in this space. This is currently true but more as a historical artifact and if we intentionally want to distance ourselves from that standard, we might benefit from a different name.

A different name would of course include more work to change wording elsewhere compared sticking to our current mixed use of "Data Package" and "data package" in the docs which doesn't stand out as obviously when used interchangeable even if they technically are different things. I'm not saying that we need or even should do this, I'm just bringing it up for discussion since the seedcase project has evolved to be less tightly couple to the Data Package standard the it was initially and I'm wondering if there would be benefits to the name reflecting that. It depends on how important you think the distinction is from the already existing Data Package standard. Some possible suggestions, none feel perfect:

Data project
Data bundle
Data product
Data artifact
Data repository
Data collection
Data capsule
Data pod
Data module
Data distribution

[signekb]

Although I actually really like the name "data package" bc it feels very clear in terms of what it is, you do have a point. Maybe open an issue for this discussion?
I think that "data pod" is pretty cute 🌱 🌷 despite it not being as clear as "data package".

[joelostblom]

Above we said that the use of python is recommended, ie not required. However, here we say that pyproject.toml is required. Changing one of them would make it more clear what we expect, and it is probably the sentence above since we talk about several other python files later.

[joelostblom]

Include a sentence about what it contains like for the other bullets?