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

Let upstream foundry coexist on the machine #741

Open
CodeSandwich opened this issue Nov 25, 2024 · 7 comments
Open

Let upstream foundry coexist on the machine #741

CodeSandwich opened this issue Nov 25, 2024 · 7 comments
Labels
feature ➕ Feature item needs triage ♟️ Issue needs to be picked up or assigned

Comments

@CodeSandwich
Copy link
Contributor

Component

Other (please describe)

Describe the feature you would like

As of now foundry-zksync conflicts with upstream foundry on the developer machine. This is fine assuming that the user will never need to compile anything for any other chain than zkSync. This assumption is obviously wrong, the users need to compile for BOTH zkSync and other chains, often as a part of the same workflow. Using foundry-zksync for anything other than building for zkSync is a mistake for a number of reasons:

  • Forks always lag behind the upstream.
  • Forks usually introduce new bugs.
  • Bugs found while using a fork have a hard time being accepted and fixed upstream.
  • Tooling built around foundry will keep using upstream foundry leading to differences. E.g. the foundry GitHub action will use a different toolkit from what the developer has on their machine.
  • Tooling expecting upstream foundry on the user machine may or may not work. E.g. Slither.
  • It's a bad practice to force the developers to change the tools for all their projects because they sometimes need to compile something for zkSync. For me it feels abusive and disrespectful, like entering a walled garden.

The solution is to allow both upstream foundry and foundry-zksync on a single machine. This would also improve the UX of foundry-zksync, e.g. by providing defaults that are sane when compiling for zkSync. The user wouldn't need to remember to pass a number of flags to forge like --zksync or --zk-compile, they could just run forge-zksync and the defaults would be correct out of the box.

Additional context

No response

@CodeSandwich CodeSandwich added feature ➕ Feature item needs triage ♟️ Issue needs to be picked up or assigned labels Nov 25, 2024
@nbaztec
Copy link
Collaborator

nbaztec commented Nov 25, 2024

Hi @CodeSandwich we already have a work stream dedicated to figuring out how to co-exist with foundry tools. The solution is unfortunately not as simple as renaming the binary, so it'd take some time until a seamless solution is available.

In the meantime, we recommend our users to either make use of either bash aliases, custom installs, or to stick to either upstream or foundry-zksync depending upon the use case.

@CodeSandwich
Copy link
Contributor Author

That's great news, I'm very happy to learn that you've been working on this problem!

Which method of installing foundry-zksync along upstream foundry would you recommend as of today?

@nbaztec
Copy link
Collaborator

nbaztec commented Nov 25, 2024

Which method of installing foundry-zksync along upstream foundry would you recommend as of today?

I'd recommend to install/download the latest foundry-zksync nightly binaries and rename them as forge-zksync, cast-zksync, etc. and put them in your PATH.

@CodeSandwich
Copy link
Contributor Author

Thanks, that's what I'll do. Out of curiosity, you wrote that:

The solution is unfortunately not as simple as renaming the binary, so it'd take some time until a seamless solution is available.

but this is literally what you're recommending to me, to have a renamed zkSync forge and cast. What are the caveats?

@nbaztec
Copy link
Collaborator

nbaztec commented Nov 25, 2024

We're currently working on a solution on a code/config-level so the foundry-zksync would be usable via foundry-upstream itself.
We opted out of renaming the binaries owing to legacy behavior, and the fact that it would be a subjective change where certain users might prefer the other way - so we'd like to fix it the right way to avoid introducing hacky interfaces like bash script renames, that the individual user can do as per their liking on their end.

@CodeSandwich
Copy link
Contributor Author

Got it, thanks for the explanation. I can't wait for the proper solution, it indeed sounds very user friendly and proper.

Should I close this issue as unnecessary since you're already working on it? Or would you prefer keeping it open to mark this problem as known?

@nbaztec
Copy link
Collaborator

nbaztec commented Nov 25, 2024

I'll keep it open to track it in our internal board, that way you also get notified when the feature lands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature ➕ Feature item needs triage ♟️ Issue needs to be picked up or assigned
Projects
None yet
Development

No branches or pull requests

2 participants