un-nest imports.lock, treat it as N SourceFiles

[Gankra]

Right now we build a mega-toml of all your imports, but this can significantly change the imported file. We should instead have imports.lock be a container format for N separate toml files, largely verbatim.

The format should be

import_name1:num_lines1
<a num_lines1 toml file>
import_name2:num_lines2
<a num_lines2 toml file>

By having the container format specify the length of its contents, we don't need any kind of escaping and can preserve the file pretty literally. This should give better diffs on updates. That said we will still be formatting it implicitly, and in #237 I am establishing that we will set criteria.description if the original input only had criteria.url.

When loading the lockfile we should also logically identify the subsections as their own SourceFiles for precise error-reporting.

[mystor]

Would it make sense for us to consider having imports.lock be a directory and having one file per import? That would certainly make things a bit simpler to implement.

[bholley]

Would it make sense for us to consider having imports.lock be a directory and having one file per import? That would certainly make things a bit simpler to implement.

I think that would lead to errors of people forgetting to git add the file. So I think the extra tooling overhead of a megafile is worth it.

[mystor]

One other option from the suggestion from comment 1 is to use a TOML file with multiline string literals for each embedded file. This would definitely lead to some nested escaping in some cases, but would be very simple for us to implement and could preserve the source file byte-for-byte.

[mystor]

Based on discussions in #272 and on matrix it looks like we're probably not taking this approach, so closing for now.