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.

Sign up for GitHub

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

Jump to bottom

Allow publishing with path dependencies without a version (RFC2906) #11133

Open
vladimir-lu opened this issue Sep 22, 2022 · 6 comments
Open

Allow publishing with path dependencies without a version (RFC2906) #11133

vladimir-lu opened this issue Sep 22, 2022 · 6 comments
Labels
A-manifest Area: Cargo.toml issues A-workspaces Area: workspaces C-enhancement Category: enhancement S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@vladimir-lu
Copy link

Problem

RFC #2906 specifies that you "No longer need both version and path 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 the version when publishing to crates.io.

Steps

  1. Create a multi-member workspace
  2. Add a dependency from one crate to another using only path = 'path'
  3. Get the error: 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

cargo 1.64.0 (387270bc7 2022-09-16)
release: 1.64.0
commit-hash: 387270bc7f446d17869c7f208207c73231d6a252
commit-date: 2022-09-16
host: x86_64-unknown-linux-gnu
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.83.1-DEV (sys:0.4.55+curl-7.83.1 vendored ssl:OpenSSL/1.1.1q)
os: Fedora 36 (ThirtySix) [64-bit]
@vladimir-lu vladimir-lu added the C-bug Category: bug label Sep 22, 2022
@epage
Copy link
Contributor

epage commented Sep 22, 2022

In #8415, we deviated from the RFC, including

Not inserting a version into path dependencies when publishing, see #8415 (comment)

@epage epage added A-manifest Area: Cargo.toml issues A-workspaces Area: workspaces labels Sep 22, 2022
@vladimir-lu
Copy link
Author

@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.

@epage
Copy link
Contributor

epage commented Sep 22, 2022

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.

@vladimir-lu
Copy link
Author

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 cargo-edit (and I guess killercup/cargo-edit#752 already tracks the change there) which is good enough in practice for me.

@jedel1043 jedel1043 mentioned this issue Sep 23, 2022
Closed
@epage epage added C-enhancement Category: enhancement and removed C-bug Category: bug labels Sep 27, 2022
@epage epage changed the title Path dependencies are not allowed to be published when using workspace version inheritance (RFC2906) Allow publishing with path dependencies without a version (RFC2906) Sep 27, 2022
fundon added a commit to viz-rs/viz that referenced this issue Dec 30, 2022
@fundon
fix(cargo): rust-lang/cargo#11133
30ba378
fundon added a commit to viz-rs/viz that referenced this issue Feb 12, 2023
@fundon
Merge branch 'main' into template-leptos
c7bbd5c 
* 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
  ...
aschaeffer added a commit to reactive-graph/reactive-graph that referenced this issue Apr 30, 2023
@aschaeffer
fix(cargo): rust-lang/cargo#11133 Not allowed publishing with path de…
cfebea1 
…pendencies without a version (RFC2906)
@epage epage added the S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. label Oct 27, 2023
@epage epage mentioned this issue Oct 30, 2023
Open
@epage
Copy link
Contributor

epage commented Oct 30, 2023

Of note, this request is the opposite of #6126

This was referenced Oct 30, 2023
Open
Open
@jaymell jaymell mentioned this issue Nov 26, 2023
Merged
@James-Mart James-Mart mentioned this issue Dec 11, 2023
Merged
@mosuka mosuka mentioned this issue Dec 30, 2023
Closed
@SamB
Copy link

SamB commented Mar 9, 2024

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.

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 version.workspace = true for several packages that doesn't imply "please version these in lockstep".

In any case, it looks like the RFC needs more notes about stuff that got changed during implementation...

@digikata digikata mentioned this issue May 6, 2024
Merged
@ErikssonJoakim ErikssonJoakim mentioned this issue Jun 2, 2024
Open
1 task
@OmarTawfik OmarTawfik mentioned this issue Jun 12, 2024
Merged
github-merge-queue bot pushed a commit to NomicFoundation/slang that referenced this issue Jun 12, 2024
@OmarTawfik
fix cargo workspace publishing (#1007)
43f22df 
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-manifest Area: Cargo.toml issues A-workspaces Area: workspaces C-enhancement Category: enhancement S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@SamB @epage @vladimir-lu