Don't enable serde's std feature

[waywardmonkeys]

When we use the serde?/std syntax for the feature, we end up with a public dependency on serde even when it isn't enabled or used. It isn't compiled, but it feels wrong. We don't need the std feature from serde, so no need to enable it and someone that does will already have it enabled.

[tomcur]

Interesting. In the case we did need Serde's std feature if Color's std was enabled, how would that be specified while bringing in Serde only with the serde feature enabled? I thought that was the intention behind this syntax.

[waywardmonkeys]

Not sure, actually! I wish we didn't have this feature at all, but we need it for Peniko for now (optional there too).

[xStrom]

we end up with a public dependency on serde

What do you mean by this?

I don't see serde with cargo tree.

# cargo tree -p color -F std
color v0.2.0

The serde dependency is also clearly marked as optional on crates.io.

Where are you seeing serde show up without specifying the serde feature?

[waywardmonkeys]

It shows up in the Cargo.lock and here:

svgtypes on  main [$] is 󰏗 v0.15.2 via  v1.83.0
❯ cargo add color
    Updating crates.io index
      Adding color v0.2.0 to dependencies
             Features:
             + std
             - bytemuck
             - libm
             - serde
    Updating crates.io index
     Locking 7 packages to latest compatible versions
      Adding color v0.2.0
      Adding proc-macro2 v1.0.92
      Adding quote v1.0.37
      Adding serde v1.0.216
      Adding serde_derive v1.0.216
      Adding syn v2.0.91
      Adding unicode-ident v1.0.14

It doesn't build, but is a bad look for when we're trying to make sure that we aren't using that stuff at all.

[xStrom]

That's interesting and frankly seems like a bug in Cargo. I might try looking more into it later, but for Color I guess it's fine to just not specify the std of serde for now.

[xStrom]

It is indeed Cargo's fault, and the issue is tracked in cargo#10801.

The issue comes from the fact that apparently Cargo has two different resolvers. One old dependency resolver, which is used to generate Cargo.lock and download dependencies. That resolver has no idea about features or anything like that. Then there is a second resolver, the feature resolver, which will use the versions from Cargo.lock and determine which actual dependencies to use and which features to enable.

The dependency resolver will generate a union of dependencies that could be used under the assumption that every platform is targeted and all features are enabled. So we had serde pop up, but others are seeing way more extreme situations, e.g. getrandom seeing 33 packages being added to the list.

The good news is that there are plenty of people who find this situation annoying and are complaining. The bad news is that a proposed potential solution includes a complete redesign of the Cargo dependency resolver and as of right now there isn't anyone doing that.