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.

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

Support workspaces #6

Open
jwodder opened this issue May 13, 2023 · 0 comments
Open

Support workspaces #6

jwodder opened this issue May 13, 2023 · 0 comments
Labels
enhancement New feature or request therefor under consideration Dev has not yet decided whether or how to implement

Comments

@jwodder
Copy link
Owner

jwodder commented May 13, 2023

The following is a list of changes that will need to be made in order for rsrepo to properly support Cargo workspaces:

  • rsrepo new:

    • Add an option for creating a workspace
    • The test.yml template should be adjusted for creating a workspace
      • Pass --workspace to all(?) cargo commands?
  • rsrepo mkgithub: When run in a workspace, the behavior should depend on whether there is a root package:

    • If there is a root package, use its metadata the same way a non-workspace package's metadata is currently used.
    • If the workspace is virtual:
      • Fetch the description & keywords to apply to the GitHub repository from the [workspace.package] table
        • Getting these fields will require parsing the root Cargo.toml directly, as they do not seem to be directly reported by cargo metadata
        • In many cases, these fields will not be set on the workspace level; what should happen then?
      • If no repository name is specified on the command line, parse the name from the workspace.package.repository field in the root Cargo.toml file, erroring if there is none
      • Look for a "WIP" repostatus badge in a README.md in the root of the workspace
      • After creating the GitHub repository, update the workspace.package.repository field if it is unset, or warn if it differs from the GitHub repository's URL
  • rsrepo release:

    • Add an option for specifying which packages to release
      • When this option is not given and running inside a package's directory, release that package
    • When releasing multiple packages at once, should a single commit with all necessary changes be made, or should there be one commit per package?
    • When releasing a breaking version of a package, update the version requirements of all other packages in the workspace that depend on it
      • Look into how cargo-release identifies such dependents
    • When publishing multiple packages that depend on each other, dependencies will need to be published before dependents
    • When running in a workspace, tags for non-root packages need to include the package name in some form
      • cargo-dist currently (as of v0.0.7) requires package-specific tags to be in the form {package_name}-v{version}.
    • Fetching a package's lastest tag will need to be done by filtering by package
    • When running in a workspace (and when releasing a non-root package?), include the package name in the intended subject line of the commit message template
    • cf. cargo-release
  • rsrepo set-msrv: Add an option for specifying which packages to operate on

    • Should there be an option for editing [workspace.package.rust-version]?
  • The code for locating a package and getting its metadata will need to be updated to work in a workspace with (or without?) specific package names specified on the command line

  • Ideally, a subcommand should be added for templating a new package in a workspace

    • The templated package should contain a LICENSE symlink pointing to the workspace's LICENSE
    • If the new package is not already matched by a glob in workspace.members, it should be added to the list
@jwodder jwodder added the enhancement New feature or request therefor label May 13, 2023
@jwodder jwodder added the under consideration Dev has not yet decided whether or how to implement label Nov 21, 2023
@jwodder jwodder added the low priority Less important than other things label Dec 7, 2023
@jwodder jwodder removed the low priority Less important than other things label May 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request therefor under consideration Dev has not yet decided whether or how to implement
Projects
None yet
Development

No branches or pull requests

1 participant