Standardized Output for file write

[brandtkeller]

Describe what should be investigated or refactored

There are a couple disparate writing processes for Lula that we should consolidate into a common approach.

Compose:

• Without -o flag will write a default component-composed.yaml to the same location as the non-composed file
• With -o flag will write file to pwd as a base for where to write the file

Validate/generate/evaluate/etc:

• Without -o flag will write a default assessment-results file to pwd
• With -o flag will write file to pwd as a base for where to write the file

Objective is to standardize the process.

[meganwolf0]

#620 makes an opinionated approach to write assessment-results to the same location as the component-definition (same logic as compose) - if that's an accepted process this could probably be closed with that issue and introduce the standardization to co-locate all OSCAL files with ones they are derived from.

[brandtkeller]

Do we have any examples we can point to for these patterns? Tooling that takes a similar stance?

1 - default to current-working-directory
2 - default to target file directory

What workflows might we need to consider?

• Validate a local file
• Validate a remote file
• Others?

Addition of an Assess command will likely follow the same decided pattern. Current thoughts for other workflows are really not-impacted across other models as they are delivering transient data.

[meganwolf0]

I think with the OSCAL models in particular, it makes sense to co-locate the derived model files (e.g., assessment-results are derived from a component-definition via lula validate, those should co-located IMO - at the very least to reduce where those could pop-up if you're working with multiple components, for instance). Those in particular make sense to me because they are seemingly part of one larger OSCAL model, and I think we've even looked at putting them in a single file for that reason (I don't really remember why we backed off that, other than just trying to avoid making a huge single file).

On the aspect of validating remote files - is that something we are looking to support? I don't believe we do currently, and I suppose if we would, then that would probably be a default to CWD because I don't really know what the alternative there would be.

Do we have any examples we can point to for these patterns? Tooling that takes a similar stance?

That's a good question, and honestly all the tools that I can think of that generate files from a CLI generally default to CWD - I mean if you want to consider like git all the files are modified in .git... but I don't know that there's really a good analogy with what we're doing with Lula. I also think if we document and it's backed by rationalization (e.g., model files are derived from each other, are really part of a single model of the system, and therefore should be co-located for clarity) then it's ok.

Anyway my 2cents, I'm obviously pro-co-location but if it's some kind of anti-pattern happy to modify

[brandtkeller]

Remote validations is something I would like to support but very much a vague vision - so lets not use that as a data point.

Otherwise I generally agree - we'll be working towards a vision of wholistic context where we want the links between files (and the use of import- fields to be meaningful. I think it makes sense for the default to be conscious of file locality for sake of these operations and future operations where the reference between files matters (or when not explicitly defining an output path - which we'd support anyway).