Skip to content

Carry forward Open Namespaces goal to 2025H2 #322

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Carry forward Open Namespaces goal to 2025H2 #322

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0b2de96
Copy open namespaces goal from 2025h1
eholk Jun 26, 2025
3c6e94c
Small updates for open namespaces for 2025h2
eholk Jun 26, 2025
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
64 changes: 64 additions & 0 deletions src/2025h2/open-namespaces.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
# Implement Open API Namespace Support

| Metadata | |
| :-- | :-- |
| Point of contact | @epage |
Copy link
Author

@eholk eholk Jun 26, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

@epage - are you still the best point of contact for this? If you'd like a break I'd be happy to put my name instead. Or @b-naber would be a good choice.

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 fine being the overall point of contact and just delegating updates to the specific team currently owning the work.

| Teams | <!-- TEAMS WITH ASKS --> |
| Task owners | <!-- TASK OWNERS --> |
| Status | Invited |
| Zulip channel | N/A |
| Tracking issue | [rust-lang/rust-project-goals#256] |

## Summary

Navigate the cross-team design work to get [RFC 3243](https://github.com/rust-lang/rfcs/pull/3243) implemented.

## Motivation

[RFC 3243](https://github.com/rust-lang/rfcs/pull/3243) proposed opening up namespaces in Rust to extension,
managed by the package name with crates-io putting access control on who can publish to a crate's API namespace.
This covers multiple teams and needs a lot of coordination to balance the needs of each team as shown on the [rustc tracking issue](https://github.com/rust-lang/rust/issues/122349).

### The status quo

- Cargo support is partially implemented.
- Compiler design is agreed on and partially implemented.
- There is a crates-io prototype for a previous iteration of RFC 3243 but that code base has likely diverged a lot since then.

### The next 6 months

- Implement Cargo and compiler support for this to be experimented with and allow crates-io work.
- Understand what changes are needed for crates.io support, and what it will take to implement these.

### The "shiny future" we are working towards

## Design axioms

Comment on lines +33 to +36
Copy link
Author

Choose a reason for hiding this comment

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

It'd be good to fill out these two sections.

As a design axiom, I think it'd be good to have something about integrating well with the resolver code, preferably leaving it simpler overall.

## Ownership and team asks

| Task | Owner(s) or team(s) | Notes |
|-------------------------------------|-------------------------------|-------|
| Discussion and moral support | ![Team][] [cargo], [compiler], [crates-io] | |
| Compiler implementation | @b-naber | |
| Work through lingering cargo issues | @epage, @b-naber | |

### Definitions

Definitions for terms used above:

* *Discussion and moral support* is the lowest level offering, basically committing the team to nothing but good vibes and general support for this endeavor.
* *Author RFC* and *Implementation* means actually writing the code, document, whatever.
* *Design meeting* means holding a synchronous meeting to review a proposal and provide feedback (no decision expected).
* *RFC decisions* means reviewing an RFC and deciding whether to accept.
* *Org decisions* means reaching a decision on an organizational or policy matter.
* *Secondary review* of an RFC means that the team is "tangentially" involved in the RFC and should be expected to briefly review.
* *Stabilizations* means reviewing a stabilization and report and deciding whether to stabilize.
* *Standard reviews* refers to reviews for PRs against the repository; these PRs are not expected to be unduly large or complicated.
* *Prioritized nominations* refers to prioritized lang-team response to nominated issues, with the expectation that there will be *some* response from the next weekly triage meeting.
* *Dedicated review* means identifying an individual (or group of individuals) who will review the changes, as they're expected to require significant context.
* Other kinds of decisions:
* [Lang team experiments](https://lang-team.rust-lang.org/how_to/experiment.html) are used to add nightly features that do not yet have an RFC. They are limited to trusted contributors and are used to resolve design details such that an RFC can be written.
* Compiler [Major Change Proposal (MCP)](https://forge.rust-lang.org/compiler/mcp.html) is used to propose a 'larger than average' change and get feedback from the compiler team.
* Library [API Change Proposal (ACP)](https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html) describes a change to the standard library.

## Frequently asked questions