feat: support native dependencies #2386
Conversation
|
So the idea is to move away from submodules, but still depend on git for fetching/updating (at least for now)? In terms of ~/.foundry/registry we could symlink to the package on platforms that support it for easier auditing/traversing and on platforms that don't we could copy |
|
One thing is that people really like that you can grep through your deps when they're in submodules. |
|
Would this not work with symlinks? Otherwise I think it would be ok to just copy and have |
|
Another idea as well: since we would have better insight into dependencies/packages, for packages that support it we can generate more "sane" automatic remappings. For example, could provide a way to add package info about your project in |
|
doubt this will make it into 1.0 so closing to keep the PRs clean. we should revisit for 2.0 |
|
+1 |
Motivation
dependency management is currently done via git submodules:
forge installInstead of managing submodules, dependencies could also be managed via a foundry registry. and a
[dependencies]table infoundry.tomlthis has the advantage that dependencies don't need to be submodules anymore and can be reuused by multiple projects.
however this introduces some challenges:
keep up to date
via submodules this is a simple update and a commit for the updated submodules. for native dependencies we can add
tag|revoptions to pin the specific commit.dependency conflict
what if there multiple versions of the same repository in the dependency graph. Currently this can only be handled via different remappings, otherwise, the top most submodule has precedence, see also #1855. in other build env this problem is handled via lock files. Unsure if beneficial here.
tooling/auditing
tracking dependencies somewhere else (~/.foundry/registry) could mean that we need to add support for existing editors/lsp so they can be found in the editor.
maybe this makes auditing harder
This PR is merely an initial exploration effort, but imo it would be possible
todo:
foundry_binderalready has some rudimentary support for thisforge buildpipeline: resolve imports, checkout, buildSolution