Create derivate csvs for collections instead of editing user-generated ones.

[bmschmidt]

Is your feature request related to a problem? Please describe.

When debugging an issue in a site, it's important to be able to start over from a clean slate. 'wax:clobber' generally allows this, but as @mnyrop notes in the issue creating it, #46, it doesn't eliminate columns that have been added to _data/{collection}.csv. So if you want to actually do a clean install, you need to maintain a backup copy of your csv and start copying it into _data.

Describe the solution you'd like
That wax overwrites a user-created file with an altered version makes me squeamish. I don't know Jekyll, but every static system I've used maintains a bright line between user generated files and program-generated ones. Like, you would never script something that adds new lines to _config.yml as part of a build process? I can't see a clearcut case where this would be disastrous, but it's nice, for instance, to have the modification date on the data csv be the date that the user actually edited it, not the last time they ran a wax build that updated it.

So just have a file at like _{collection}/{collection}.csv that wax creates which is the user csv from _data/{collection}.csv but with the columns order,layout,collection,thumbnail,full,manifest, and whatever else you're creating added.

Describe alternatives you've considered

Leave it as is? I don't know what you're thinking of to allow this to get clobbered.
I've occasionally used a solution of having something called catalog_derived.json in the same folder, but using the collection folder seems more robust to me.

Additional context
Add any other context or screenshots about the feature request here.

[mnyrop]

@bmschmidt agreed. in classes we have folks create a copy, e.g., qatar-original.csv but this is super clunky / not documented. since folks can go the BYO manifest route and use an institutional repository IIIF resource on some items and chose local on others, we can't know what was wax-generated and can't fully clobber.

I do think we could treat the original metadata file more like the source images and generate a separate metadata file (with wax additions) that is treated like a disposable derivative itself.

Regardless, this is an issue I'm keeping an eye on. Since it would be a breaking change, I'm waiting to get more community feedback in classes &etc before making a decision for v2. I'll definitely keep your perspective in mind.

[bmschmidt]

Out of curiosity, what would it break to use an intermediate file that updates from the user file?

[bmschmidt]

Two related questions, one at a time: what does a breaking change mean for Wax? Is it the API (which is... the task names?), or is it that a website generated by it will look different/have different URLs?

[bmschmidt]

Second: where does the 'full' field in the CSV get generated? After running wax:derivatives:iiif, I have 'thumbnail' populated in my markdown yaml headers and csvs, but not full. I'm terrified to run wax:derivatives:simple while the site is working, so instead I'm just adding in a field for full on each md file defined as f['full'] = f['thumbnail'].replace("250,", "full").