Tracking issue for namespaced-features

[djc]

Docs: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#namespaced-features
Original issue: #1286
Implementation: #5300

Not sure what the process is for stabilizing experimental Cargo features, I figured a tracking issue might be useful? @alexcrichton any guide on what should be done to move this towards stabilization?

Unresolved issues

• Figure out how to deal with breakage of Cargo versions older than 1.19. Add schema field and features2 to the index. #9161

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

[alexcrichton]

Indeed a tracking issue is useful! I think though this still has a large piece to implement which is to propagate namespaced features to the registry index

[djc]

Yes, I figured as much. So do you have any ideas/guidance about how to go about that? Are there established ideas on how to evolve the registry index?

[alexcrichton]

The evolution here is just a new key in the registry which we've done a bunch of times before, so it's fine to do whenever once there's an agreed up on design. Most of the time this is hard to undo though so we want to be pretty sure of the design before it lands. Technically it'll involve modifying crates.io as well as the publishing code in Cargo to send more data to the registry

[djc]

Can you be a bit more specific about which parts of the cargo and/or crates.io code need changing?

[alexcrichton]

You may want to hop onto the crates.io channel on discord as they may know more, but it's all around krate.rs and git.rs IIRC

[djc]

@alexcrichton okay, so, I'm still not entirely clear on what needs to be done on the crates.io side here. Is it just propagating the package.namespaced-features value? The feature values can still be serialized as a string, so that's the least invasive change. Alternatively, we could add more structure to the feature values and use serde's enum handling to have a new key that's more explicit about what's what.

Either way, I'm not sure how the compatibility with old cargo is supposed to work, or who all needs to be on board with a supposed design.

[alexcrichton]

@djc there's a few things here I think that we'd need to consider:

• One aspect is that we need to consider what happens when older versions of Cargo are used. For example if I use Cargo from 1.20.0 with a crate that has a namespaced feature, what happens? Is an error generated? Does the package not exist? Does it silently work sometimes and not others? My preferred way to solve this would be to add support for this today but don't actually allow publishing crates just yet. That way after a few cycles and Cargo rides the trains older Cargo will be able to understand newer crates in the future.
• Next is the actual registry format itself. Right now the features in the registry index are just an array of strings, but presumably yeah we'll need to propagate the namespaced features boolean as well. New registry fields could be used as well.

Before we go much further though I think it'd be good to get weigh-in from @rust-lang/cargo because once we start changing the registry it's sort of the point of no return

[joshtriplett]

@alexcrichton So, this is exactly the kind of change that really motivated the idea of supporting Cargo version dependencies in a way that older versions of Cargo can handle.

We can't make old versions of Cargo unable to parse new versions of the index; that's a serious problem.

If we're going to do this, we need to version the index, such that older versions of Cargo don't see crates that use this feature at all.

[alexcrichton]

@joshtriplett indeed! To be clear though the main issue is that an older Cargo won't understand the newer index, but we get to control how it doesn't understand the new index as well (aka no features, a mapping of features, or something like that). Having a fully versioned index seems far off still so I'd be fine implementing this before that comes along.

Now having a versioned index is a good idea though and we can start at any time to add safeguards into Cargo to avoid looking at future revisions!

[alexreg]

Is this going to move towards stabilisation soon?

[djc]

Probably not -- I'm still motivated to write code to move this forward, but I don't know exactly what needs to be done.

[alexreg]

Oh, I thought it was already implemented, just needed stabilising.