-
Notifications
You must be signed in to change notification settings - Fork 66
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
feat: shared workspaces #1145
feat: shared workspaces #1145
Conversation
This builds and passes tests locally, but there are several outstanding TODOs, and this isn't really tested until we change the gallery. |
69393d9
to
c6aee9f
Compare
97eceef
to
cb829e6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally, I like this. The WorkspaceGraph
interface is nice and clean, and I appreciate how it looks / gets used within cargo-dist. I'm mainly wondering about the couple bits of pseudo-private data and what the plan is for those.
#[derive(Debug, Error, Diagnostic)] | ||
pub enum ProjectError { | ||
/// No workspace found from axoproject | ||
#[error("No workspace found; either your project doesn't have a Cargo.toml/dist.toml, or we couldn't read it")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we also want to mention dist-workspace.toml
?
75aad7b
to
7a1964b
Compare
/// The unoverrideable name of the package within its own package management system. | ||
/// | ||
/// This may be needed when e.g. talking to cargo about the package. | ||
pub true_name: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Smart plan.
This introduces a new axoproject WorkspaceGraph abstraction that exists to replace the old Workspaces approach. The purpose of this new abstraction is that it supports nested workspaces, while still allowing you to work with all the packages uniformly. Most code largely remains the same, as it looks up properties of packages by id, or queries a property of all workspaces/packages, where essentially nothing is changed. Also all logic to inherit config from workspaces to packages is just changed to inherit from the *root* package, as we don't want to support multiple `[workspace.metadata.dist]` entries. compute_build functions have been changed to take a workspace, so that we try to compute N cargo builds for N cargo workspaces (discarding them if unecessary). The URL code has once again been refactored to be more of a chain instead of redoing the same work over and over. The `package_info` subfield of a workspace has been deprecated in favour of Asking the WorkspaceGraph, as there are different tiers of childhood now.
This introduces a new axoproject WorkspaceGraph abstraction that exists to replace the old Workspaces approach. The purpose of this new abstraction is that it supports nested workspaces, while still allowing you to work with all the packages uniformly.
Most code largely remains the same, as it looks up properties of packages by id, or queries a property of all workspaces/packages, where essentially nothing is changed.
Also all logic to inherit config from workspaces to packages is just changed to inherit from the root package, as we don't want to support multiple
[workspace.metadata.dist]
entries.compute_build functions have been changed to take a workspace, so that we try to compute N cargo builds for N cargo workspaces (discarding them if unecessary).
The URL code has once again been refactored to be more of a chain instead of redoing the same work over and over.
The
package_info
subfield of a workspace has been deprecated in favour of Asking the WorkspaceGraph, as there are different tiers of childhood now.