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

support --profile cli argument #7859

Closed
sakulstra opened this issue May 5, 2024 · 5 comments
Closed

support --profile cli argument #7859

sakulstra opened this issue May 5, 2024 · 5 comments
Labels
T-feature Type: feature

Comments

@sakulstra
Copy link
Contributor

sakulstra commented May 5, 2024

Component

Forge

Describe the feature you would like

It would be good if --profile could be specified as cli argument for forge test and forge script

The original issue I tried to solve is the following:

is there a way to specify evm_version per network (or more broadly, is there a way to specify compiler options per network)?
We're currently facing some issues on a multi-chain foundry project were some external contracts use push0, but if we just change https://book.getfoundry.sh/reference/config/solidity-compiler#evm_version to shanghai it will silently start breaking on e.g. metis (which still doesn't support push0).

As i think there currently is no way to do this, my idea was to "work around" the problem by introducing "per chain" profiles(e.g. profile.polygon) and using the correct one based on the chain alias. Setting the profile via FOUNDY_PROFILE env is cumbersome though. It would be nice if it could be just part of the script/test command.

Additional context

I think per chain compiler config would be a quite good(but ofc more complex) feature especially when shipping with reasonable defaults. Currently the evm landscape is quite hard to maneuver due to subtile changes. Having e.g. metis "default" to pre istanbul could make a lot of sense.

@sakulstra sakulstra added the T-feature Type: feature label May 5, 2024
@mattsse
Copy link
Member

mattsse commented May 5, 2024

I think per chain compiler config would be a quite good(but ofc more complex) feature especially when shipping with reasonable defaults. Currently the evm landscape is quite hard to maneuver due to subtile changes.

investigating and scoping this currently, but yes this is a bit more complex

cc @klkvr

@mds1
Copy link
Collaborator

mds1 commented May 5, 2024

Per chain compiler config related to #7720. It proposes a UX for different profiles per contract, probably would need to be tweaked for this purpose

@sakulstra
Copy link
Contributor Author

sakulstra commented May 5, 2024

@mds1 yah seems related but quite different as the suggestion it's factually a bit of the opposite.

In practice I want to run the same contract on 12 chains, but on one a few i need paris were on some others i need shanghai. In fact for me would be fine to run paris on all chains, but in this particular case one of the external contracts used, was deployed with shanghai ... so if i use paris the tests will fail with an evm error(as push0 doesn't exist yet in the test environment).

In my naive view a "per network" config would be the perfect solution, but honestly idk if it's even possible to do.
As you can do things like vm.createSelectFork(randomStringPotentiallyFromEnv) at any point in your test i guess it's impossible to know the target network at compile time(also, i think while we never do it, it's possible to have a single test fork multiple networks makin "target network" somewhat arbitrary)?

Probably for now, having --profile be a thing would be a good enough workaround

@sakulstra
Copy link
Contributor Author

Actually one related issue here is caching:
seems like the cache is currently per file/solc version, but not per evm_version so changing evm_version always forces a complete recompile which on bigger projects is painful.

@zerosnacks
Copy link
Member

Marking as duplicate of #5479

@zerosnacks zerosnacks closed this as not planned Won't fix, can't repro, duplicate, stale Jul 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-feature Type: feature
Projects
None yet
Development

No branches or pull requests

4 participants