boulder: Auto update the index for local collections.

[joebonrichie]

Saves the packager a manual extra step after putting new .stones into the local collection.

Resolves #11

[ermo]

@joebonrichie

Any chance you would be willing to look into sunny's suggestion too?

This would be a really nice feature; update prior to building and then copy + update by default after building if a profile flag is supplied. It might make more sense to have a --nocopy/n flag for when you don't want to copy the built .stones to the local profile collection?

The logic would be something like IF -p is supplied, THEN files are copied unless -n is also supplied. -n cannot be supplied without -p

[joebonrichie]

Can do, but it should be a different PR

edit: So i'm thinking just collect .stone assests into local collection and reindex? We end up indexing twice in that situation if we always auto update the index for local collections. Unless we just collect .stone assests with the -p flag and don't reindex.

[ermo]

Can do, but it should be a different PR

edit: So i'm thinking just collect .stone assests into local collection and reindex? We end up indexing twice in that situation if we always auto update the index for local collections. Unless we just collect .stone assests with the -p flag and don't reindex.

My modified thinking is "index at the start of each run" and "copy assets into the specified profile's local collection at the end of run" (subject to the logic mentioned above) and just don't index after.

Then you also catch any .stones copied in manually if someone forgot to re-index?

In general, I feel like moss and boulder would do well to re-index local collections prior to each running. That would likely be the most ergonomical thing to do re. having local collections in any case as sunny alludes to.

Can you think of any cases where you don't want local collections automatically re-indexed prior to moss/boulder runs?

[joebonrichie]

so do you want to hack into output directory (-o) or have two copies of the .stones, one in /var/cache/boulder/collections/local and one copy in output directory?

[ermo]

so do you want to hack into output directory (-o) or have two copies of the .stones, one in /var/cache/boulder/collections/local and one copy in output directory?

We need manifest.bin and manifest.jsonc in the recipe dir (for commit purposes) and it's still useful to be able to inspect the stone in the recipe dir afterwards.

Hence, I'd use hardlinkOrCopy on the .stone when -p is specified (and -n is not) and ask the profile about its associated local collection target dir. In the case with several different profiles with associated local collections, that makes the most sense I think.

From what I understand, -o outputs everything to the output dir, which is not really what we're after?

My perspective in this is that we're trying to figure out what works and feels ergonomic and this is a good step on that path I think. I'd add an info() message to the hardlinkOrCopy step so it gets captured in the log output.

[ikeycode]

I agree that promotion to collection is a separate PR. Lets get this in. @joebonrichie thank you!