Not relevant for this questions
Hey, I was checking out the openzeppelin-upgrades package. It looks awesome, but I had a couple questions.
The README says,
At the moment the plugins do not support upgradeable contracts linked to external libraries. This is because it's not known at compile time what implementation is going to be linked thus making very difficult to guarantee the safety of the upgrade operation.. My question is, does this mean the plugin won’t allow you to deploy a contract that uses an external library, or just that it’s unsafe?
I’m currently using a library for some math operations, and the library is rather long. If I include it directly in my contract, then the contract becomes too big. If I make it a library and link it to my contract, then it sounds like OZ won’t support this, and thus I can’t use OZ to write this as an upgradeable contract? Considering I control this library, it seems like I should be able to “force” OZ to use it as a linked library.
It seems like this restriction should be similar to the “custom structs” restriction which is that you have to pass a flag that says “unsafeUseLibrary” or something. But the docs don’t make that clear.
2.) Does this library support “regular” deployments? I’d love to use OZ for the project.json files it spits out, but I want it full programmatic control. It seems like my current options are to use the CLI (which gives project.json files, but is a bit hackier to use in a script, though not impossible), OR to use the contractLoader, which can deploy, but doesn’t save a project.json file OR use the upgrades library which is programmatic and creates a project.json, but doesn’t support regular deploys. Am I seeing all those options correctly, or am I missing something?
Code to reproduce