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

RFC: Nested Cargo packages #3452

Open
wants to merge 34 commits into
base: master
Choose a base branch
from
Open

RFC: Nested Cargo packages #3452

Changes from 1 commit
Commits
Show all changes
34 commits
Select commit Hold shift + click to select a range
80b9ddf
Create 0000-nested-publish.md
kpreid Jul 1, 2023
126b2b4
Clarify some terms and discuss workspaces and normalization
kpreid Jul 1, 2023
ef9a157
Discuss trait coherence relaxation
kpreid Jul 1, 2023
a1d4425
Reposition footnote-links
kpreid Jul 1, 2023
35184e0
Add PR number
kpreid Jul 1, 2023
c4dd372
Clarify `path` behavior and existing dev-dependency behavior
kpreid Jul 1, 2023
e71a953
Avoid "lockstep" and discuss a version duplication hazard
kpreid Jul 1, 2023
3da9eeb
Add Definitions section.
kpreid Jul 6, 2023
7f9c09f
Discuss more alternatives for marking packages; define "nested package"
kpreid Jul 6, 2023
130ceb0
Clarify “is private”
kpreid Jul 6, 2023
42bdb61
Require dependencies to be explicitly nested.
kpreid Feb 5, 2024
25d86b1
More motivation and drawbacks.
kpreid Feb 5, 2024
743d531
Define “nested publishing”.
kpreid Feb 5, 2024
34a19dc
Discuss postponed RFC 2224 as prior art.
kpreid Feb 5, 2024
b75a519
Mention vendoring.
kpreid Feb 5, 2024
d7e8dea
Discuss “subcrate dependencies” in prior art.
kpreid Feb 5, 2024
6670428
Discuss “Inline crates” in prior art.
kpreid Feb 5, 2024
da547de
Rewrite reference-level explanation to focus more on effects than cha…
kpreid Feb 5, 2024
b4923ac
Expand alternatives and move inline-crates discussion there.
kpreid Feb 5, 2024
68ad634
Move license and version ideas.
kpreid Feb 11, 2024
33d1c6e
Specify that package names must be unique.
kpreid Feb 11, 2024
680709c
Typo
kpreid Feb 11, 2024
2af4921
Mention feature flattening.
kpreid Feb 11, 2024
0deba10
Discuss workspace inheritance.
kpreid Feb 11, 2024
b999976
Move `dependencies.*.publish = false` to future possibilities.
kpreid Feb 11, 2024
3edb308
Replace `package.publish = "nested"` with `package.publish.nested = t…
kpreid Feb 11, 2024
dd90f20
Refine explanation of `package.publish` being a table.
kpreid Feb 11, 2024
07b058d
Rephrase name conflict rule to avoid "transitive closure".
kpreid Mar 11, 2024
2c220ee
Always error on `workspace.dependencies.*.publish`.
kpreid Mar 11, 2024
4bc77cb
Rewrite feature flattening section.
kpreid Mar 11, 2024
e470314
Rationale for name uniqueness.
kpreid Mar 13, 2024
2a5474e
Polishing.
kpreid Mar 13, 2024
db9e7fa
Update comparison with packages-as-namespaces given that that RFC has…
kpreid Mar 13, 2024
4817861
Explicitly state that nested names are non-unique *outside* of the pa…
kpreid Mar 13, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Rewrite feature flattening section.
  • Loading branch information
@kpreid
kpreid committed Mar 11, 2024
commit 4bc77cbde5ac3473aceee2b80b92ced545ba666b
9 changes: 6 additions & 3 deletions text/0000-nested-publish.md
View file
Open in desktop
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A minor question: If a Git repository contains a package with nested packages, can the other package depends on any of those nested packages as a Git dependency? Currently Git dependency searches packages whose name matches recursively inside the repository.

Original file line number Diff line number Diff line change
Expand Up @@ -177,9 +177,12 @@ When a valid parent package is packaged, each of its transitive nested dependenc

The package index, and the `crates.io` user interface, does not explicitly represent nested packages; the package is presented as if it were a single package:

* Nested packages' dependencies are flattened into the dependencies of the parent package.
* The packages selected by nested packages' features must be rewritten in terms of the parent package's features.
* Note that optional dependencies might become required if the parent package always enables the relevant feature, and required dependencies might become optional if the dependency on the nested package is optional.
* Nested packages’ dependencies are flattened into the listed dependencies of the parent package.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little concerned that this seems like it could be a fairly complex operation to flatten dependencies. For example, how does it handle name collisions? How does it handle fields that aren't normally unified, like the public field? I'm not quite sure I see how this could work.

If the intent is to have the resolver not know about nested packages, it seems like that would make it difficult for other parts of cargo to know about those nested packages since they are all driven by the resolver.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another field that can't be readily merged is links. Is it an error to have more than one links in the tree?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don't hide this from the resolver, that opens up other areas of complexity

iiuc

  • we would need a way for source ids to refer to these packages
  • we would need a way to include these entries in the Index without conficting

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By merging dependencies we probably have to mean that the index will list all of the dependencies from the merged list. I.E. the list of dependencies will have more than one entry for foo. Rather than us merging all references to foo into one dependency. I Think, the resolver already has to deal with index entries with duplicate package names, for target specific dependencies and rename dependencies.

If we actually want to merge into one dependency entry, semver constraints are going to make life difficult. >=1.0.0-alpha, <3.0.0 is not the merger of >=1.0.0-alpha with <3.0.0. (1.0.0-alpha matches the first two but not the third one).

* Each optional dependency of a nested package so flattened must accurately represent the conditions for its activation in terms of the parent package's features (or lack thereof). To illustrate, note that the following cases might occur:
* Optional dependencies of a nested package can become required, if the parent package always enables the relevant feature of the nested package.
* Required dependencies of a nested package can become optional, if the dependency on the nested package which has that dependency is optional.
* Optional dependencies that stay optional must be listed as activated by the relevant feature(s) of the parent package; the feature names of nested packages never appear in the index.


All together, this will reflect what can be expected when using the parent package, without revealing, or needing to represent, the nested package implementation details of the parent package.

Expand Down