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 sub-dependency locking for package versions compatibility #211

Open
palinatolmach opened this issue Oct 9, 2024 · 1 comment
Open
Labels
question Further information is requested

Comments

@palinatolmach
Copy link

It would be helpful if Soldeer introduced a mechanism for sub-dependency locking to avoid conflicts and integration issues if package versions are not aligned.

For example, while it's not a strict requirement, we recommend that users of Kontrol cheatcodes also install newer versions of Foundry standard library forge-std (>= v1.9.3) to maximize compatibility between cheatcodes.

@beeb
Copy link
Collaborator

beeb commented Nov 6, 2024

Hey! Thanks for the suggestion. I think this would require a radically different handling of subdependencies than we have now.

At the moment, the system is pretty simple: for each dependency that is a foundry project, run the forge soldeer install or forge install command in the dependency's directory. Each dependency can have its own soldeer.lock where the exact version is specified and that will be the installed version.

This works and is desirable in most cases because each project can use their own requirements and their own remappings and foundry will resolve that correctly.

Regarding your use-case you would like to specify in the kontrol-cheacodes dependency, that any dependent uses forge-std>=1.9.3 alongside kontrol-cheacodes? I think this is better done as documentation personally.

Since dependencies are not flattened, we don't have a reason to perform a resolution step to find a single version that would match all direct and transitive dependencies requirements. And because of foundry's remappings mechanism, having all dependencies installed at the top-level would likely not work.

@beeb beeb added the question Further information is requested label Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants