Daml upgrade and duplicate modules during codegen

[Stephen]

I suggest introducing a unique module-prefix for v1 and each future version. This is stable with respect to current references to v0, and defines a path that will remain stable for v1 immediately as you introduce it, and with each future version as well.

@Thibault

not really for Utils which hasn’t changed, but all references to it in the code now need to be updated

The problem with placing unchanging modules in the same package as changing modules is that, fundamentally, they all change. In the topology you’ve described, Utils all get new package IDs to go along. That makes them distinct with respect to the ledger API, which is more-or-less the primary target of codegen, and means that dealing with that distinction is something you cannot avoid. Having two generated copies of Utils is the most straightforward way of being able to deal with that distinction.

If you want Utils to “not change”, then it genuinely needs to be in a separate Daml package, not just a separate module. We split up the standard library for a similar reason:

Should we maintain a daml 'base' or 'prelude-next' library?

I’d like to add one more point to think about: You probably don’t want to have any data types that are intended to end up on a ledger in such a library. If you change your library or have to recompile it with a different version of the SDK, you will end up with a different package ID and hence the types are considered different. For daml-stdlib, we jump through quite some hoops to get stable names for type like Either. More precisely, we put each such type in its own package without anything el…

For the same reason, we recommend putting triggers, scripts, and such in separate packages, so that they can be altered with reckless abandon without having any on-ledger implications.