Feature Discussion: mops promote #281
Description
In a discussion with @canscale the idea of being able to add a package that you want included insource came up. For example, for ICRC 1/2/3 tokens you may want to have the library code as part of your project so that it is easy for 1. Devs to modify and 2. People to verify.
Now obviously if you change the code you are no longer using the same library, but a fork of a library. Perhaps the diff ends up being 1 line or perhaps you fundamentally change the behavior to the point that you'd want to really fork.
The main goal here is to identify something as being from a 'known good' package and then to be able to easily see the changes that were made.
I'm going to throw something out that may be stupid, complicated, unwieldy, or all three of those, but I'll do so just to spur discussion.
Example workflow:
mops promote icrc1-mo -> this would add the current version icrc1 to my mops file under [promoted-dependencies] and put the files in a src/mops/icrc1-mo/ folder. Perhaps this is even a git submodule? I'm not sure about that particular feature.
Upon mops sources, the tool would check the hash of the current icrc1-mo file matches what it expects of the version in [promoted-dependencies] and throw a warning if they don't match. On the mops page if you use one of these and they don't match you would be able to show the changes(if the item is later published to mops). Git is obviously good at this.
We wouldn't want to replicate git...but maybe that is what we're actually trying to do here.
I suspect a better solution here is to develop some best practices for building event patterns, validation patterns, and interceptor patterns so that 'known good' libraries can be easily modified using event handlers passed to the classes, but this was suggested as an alternative and I though it would be worth discussion.