-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Allow publishing with path dependencies without a version (RFC2906) #11133
Comments
In #8415, we deviated from the RFC, including
|
@epage Thank you for pointing me to the discussion. Do you know if something was decided about this in the future (perhaps a workspace flag like for other workspace-inheritance related usages right now)? Otherwise I guess this can be closed. |
If it were to move forward, it will need to be re-examined from scratch. It didn't get the attention it needed in the initial RFC and has breaking changes and bad workflows that would need to be addressed. While its a neat idea, I don't think it would end up being worth the effort in practice. |
As a user, the ability to keep the version consistent across the entire repo (here represented by a cargo workspace) is very useful, even if it means republishing new versions for crates where nothing changed, because of the simplicity of dealing with a single version rather than multiple. I can also see the argument why semver might imply that you should probably publish the most minimal version increment possible (what was being argued in the RFC comments), though for monorepo-managed applications that are also published to a registry there doesn't seem much practical benefit vs. the library case. Right now, the workaround is to use |
* main: (37 commits) chore(core): csrf: use base64 0.21 api chore(deps): update chore(examples): limits (#69) chore(core): deps: cookie-0.17 fix: limits should be sorted chore(deps): core: form-data-v0.5.0-rc.1 chore(funding): update chore(funding): update doc: fix discord link doc: update viz link chore: docs chore(core): body: poll ? fix: cargo fix(cargo): rust-lang/cargo#11133 fix(core): clippy chore(core): clippy fix(core): clippy chore(core): clippy doc: add langs links chore(deps): hyper v1.0.0-rc.2 ...
…pendencies without a version (RFC2906)
Of note, this request is the opposite of #6126 |
Um, isn't the idea to publish all of the packages that inherit their version from the workspace in one go? I guess this would need protocol changes, but does it actually break any code or workflows? I can't see any way to interpret setting In any case, it looks like the RFC needs more notes about stuff that got changed during implementation... |
Currently our publishing pipeline is failing to publish workspace crates that have internal dependencies: https://github.com/NomicFoundation/slang/actions/runs/9468852124/job/26088399371 ```log error: all dependencies must have a version specified when publishing. dependency `metaslang_cst` does not specify a version ``` This is a known bug/limitation of `cargo publish`: rust-lang/cargo#11133 To get around this, I'm explicitly adding versions to all internal dependencies, and switching our versioning workflow to use `cargo set-version` to update all of them when creating the changesets PR.
## Description This should [unblock](https://github.com/FuelLabs/sway/actions/runs/11035362451/job/30652169645#step:4:22) releases. [Cargo doesn't use the workspace version for path dependencies](rust-lang/cargo#11133), so we still have to specify the versions. This is also how it's done in [fuel-core](https://github.com/FuelLabs/fuel-core/blob/master/Cargo.toml). This is actually nice because it means we could in the future bump the versions of the dependencies separately, all from within the one file. ## Checklist - [ ] I have linked to any relevant issues. - [ ] I have commented my code, particularly in hard-to-understand areas. - [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book). - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose) - [ ] I have added tests that prove my fix is effective or that my feature works. - [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant. - [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md). - [ ] I have requested a review from the relevant team or maintainers.
Problem
RFC #2906 specifies that you "No longer need both
version
andpath
to publish to Crates.io" here. Now that the tracking issue #8415 is in stable I feel like it's a missing feature aka a bug.The problem is the one described in the RFC - a multi-member workspace should be able to specify
mod-a = { path = "path-to-mod-a" }
without specifying theversion
when publishing to crates.io.Steps
path = 'path'
error: all dependencies must have a version specified when publishing.
Possible Solution(s)
No response
Notes
My apologies if this was already covered somewhere else but a search and reading through the comments on the RFC didn't yield anything about why this is not implemented. Or perhaps I just haven't found the way to do this yet and the docs need an update to clarify.
Version
The text was updated successfully, but these errors were encountered: