Unpin all non-stellar dependencies #1441
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Supersedes #1351 |
leighmcculloch
requested review from
graydon,
sisuresh,
dmkozh and
a team
as code owners
dmkozh
approved these changes
Aug 16, 2024
leighmcculloch
added a commit
that referenced
this pull request
Aug 20, 2024
### 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 #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. (cherry picked from commit a54d997)
github-merge-queue bot
pushed a commit
to stellar/rs-soroban-sdk
that referenced
this pull request
Aug 20, 2024
### What Update soroban-env-* to 21.2.1 ### Why To get a release of soroban-sdk with the unpinning of deps in env: - stellar/rs-soroban-env#1441
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 #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.