Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change the management of all chains to an homogeneous way as profiles. #2052

Open
jmoreira-valory opened this issue Sep 12, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@jmoreira-valory
Copy link
Collaborator

jmoreira-valory commented Sep 12, 2023

Currently, the framework has some chains defined with a profile (e.g., Ethereum) and some other chains to be defined with "custom profile" that requires environment variables to be defined (e.g., Polygon).

The suggestion is to use profiles homogeneously for all the chains that we control, and leave "custom chain profile" only for actually user-defined chains.

The reasoning for adopting this solution was to avoid multitude of flags on the CLI (--use-ethereum etc.) However, altough this solves the problem of multitude of flag, it introduces the burden of keeping the user informed of the on-chain changes through the documentation, and the user needs to update a significative number of environment variables .

The current "workflow" would be
1- Some contract gets updated
2- Framework documentation gets updated accordingly
3- User needs to be aware of this update in the docs and change their environment variables accordingly.
4- Use the commands

With the proposed approach, if we have profiles for all relevant chains that the DAO deploys the contracts, the workflow would be:
1- Some contract gets updated
2- Framework updates the profile
3- User needs to use the commands with the latest version of the library. No need to redefine environment variables, etc...

Obiously, both approaches have drawbacks, but the first one seems to be more error-prone for the user, as they need to be very aware of the changes ongoing, and where to find this information. The proposed solution requires "only" that the user has the library updated.

Bonus:
Although this would not bring much benefit from the point of view of implementation, seems that the ideal solution would be having a flag --profile instead of multiple mutually-exclusive flags on the commands. This however, might introduce backwards-incompatible changes.

@DavidMinarsch DavidMinarsch added the enhancement New feature or request label Sep 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants