We have had reports that the libs are difficult to integrate into other projects due to the rigid dependency requirements.
We ultimately need the dependencies to be pinned in stellar-core.
There's benefit to the tests in this repo running with the same dependencies as what core pins to.
There's benefits to stellar-rpc also using the same dependencies so as to decrease the chance that simulation runs with different behavior. Also, the same applies to the SDK for test behavior.
Pinning the deps were an easy way to keep the dependencies consistent everywhere, but it also makes it difficult for folks to use the env libraries.
@graydon is making a tool to check that Cargo.lock files are using consistent versions where possible across the env repo, core repo, and we can also use that in the rpc repo. It won't be practical to expect contract devs to use it on their contract projects, so contract devs will be able to use whatever combination of dependencies and that's just a limitation.
Why not
We could say again that not doing this has greater benefits than allowing folks to more easily use the libraries in their own projects.
leighmcculloch
commented
1 month ago
What
Unpin all non-stellar dependencies.
Why
We have had reports that the libs are difficult to integrate into other projects due to the rigid dependency requirements.
We ultimately need the dependencies to be pinned in stellar-core.
There's benefit to the tests in this repo running with the same dependencies as what core pins to.
There's benefits to stellar-rpc also using the same dependencies so as to decrease the chance that simulation runs with different behavior. Also, the same applies to the SDK for test behavior.
Pinning the deps were an easy way to keep the dependencies consistent everywhere, but it also makes it difficult for folks to use the env libraries.
Close https://github.com/stellar/rs-soroban-env/pull/1351
Other things that need to happen
@graydon is making a tool to check that Cargo.lock files are using consistent versions where possible across the env repo, core repo, and we can also use that in the rpc repo. It won't be practical to expect contract devs to use it on their contract projects, so contract devs will be able to use whatever combination of dependencies and that's just a limitation.
Why not
We could say again that not doing this has greater benefits than allowing folks to more easily use the libraries in their own projects.