1475691 - Publish servo_arc on crates.io

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, enhancement, P3)

Description

[Manish Goregaokar [:manishearth]]

We currently have a crate, servo_arc (https://searchfox.org/mozilla-central/source/servo/components/servo_arc/lib.rs), which contains a tweaked Arc along with a bunch of related types.

I think this would be generally useful for the general rust community; I've certainly needed things like ArcBorrow and Arc+HeaderSlice before.

We should probably publish this on crates.io (perhaps call it "plasma" or "arc-second" or "triomphe" or something so it's not "servo_arc"?)

It doesn't seem like we're modifying it that much in tree as well, so perhaps we should move it out of tree to a github repo and use it with its crates version number?

I can do the work of documenting and moving everything around (I can extract it preserving commit history), just need folks to agree that we should do this.

Comment 1

[Bobby Holley (:bholley)]

Note that servo_arc is already on crates.io: https://crates.io/crates/servo_arc . I'm not sure how up-to-date it is.

I don't think we want to move the source to github, at least from m-c's perspective. There's a lot of value in being able to quickly and easily add things to it. I'm fine with renaming it to whatever we think is appropriate, and periodically publishing to crates.io.

Comment 2

[Manish Goregaokar [:manishearth]]

The reason I want to split it out is that it's easier for others to contribute too, and with luck we can get a lot of other users who help make it better.

But we can also keep it in tree.

An alternate route is to just maintain a fork on github and if there ends up being activity, manually sync or just let it diverge into a different project with more general goals -- i.e. folks may want more Arc-things that we don't need.

Either way, I'll start documenting it (more) soon, and we'll pick a name that doesn't say "servo" later.

Comment 3

[Bobby Holley (:bholley)]

(In reply to Manish Goregaokar [:manishearth] from comment #2)
> The reason I want to split it out is that it's easier for others to
> contribute too, and with luck we can get a lot of other users who help make
> it better.
> 
> But we can also keep it in tree.
> 
> An alternate route is to just maintain a fork on github and if there ends up
> being activity, manually sync or just let it diverge into a different
> project with more general goals -- i.e. folks may want more Arc-things that
> we don't need.

Yeah, this seems like a good approach. It feels to me like this is unlikely to be a high-activity crate, so manual syncing is fine. I think we should keep the bar for accepting contributions at "something we might plausibly use", at which point it seems reasonable to have in the tree (pay for what you use). So I don't think it's all that likely we'd need to diverge.

> Either way, I'll start documenting it (more) soon, and we'll pick a name
> that doesn't say "servo" later.

Triomphe is clever, as would be Noah and Joan.

That said, there's real value in stuff being easily understandable rather than funny. So I think I probably prefer just mozarc (which also happens to be one character away from mozart, so it's still a little bit funny).

Comment 4

[Emilio Cobos Álvarez (:emilio)]

I think the process for editing crates.io crates is not too terrible these days... So the advantage would be to only land the changes more easily, right?

Comment 5

[Xidorn Quan [:xidorn] UTC+11]

I would support splitting servo_arc into a separate repo and maintained out-of-tree.

Looking at its history, in the last half year, there were only 8 commits to servo_arc, and the last change was April 29th, which is over two months ago.

Comparing to selectors which has 7 commits in just June, and even cssparser is more active, apparently it isn't in heavy development nowadays from our developers, so I don't see how keeping it in-tree has much value for us.

As emilio said, nowadays editing vendored third_party crate isn't that hard with the [patch] section in Cargo.toml. We can even vendor a patched version like what we've been doing for serde_derive[1] when necessary.


[1] https://searchfox.org/mozilla-central/rev/448f792f9652d29daebdad21bf50b03405e40a45/Cargo.toml#63

Comment 6

[Bobby Holley (:bholley)]

I think removing the in-tree version of servo_arc is premature.

Publishing it on crates.io is fine, and publishing it in a git repository is fine. If we see significant external contributions to that repo, and those contributions are useful to us, and the work of applying those changes to m-c is large enough to outweigh the benefits of being able to patch the code directly, then we should consider making our in-tree copy read-only (i.e. moving it to a crates.io dependency).

Making it read-only before then would be imposing a concrete development hurdle for gain that has yet to materialize.

Comment 7

[Manish Goregaokar [:manishearth]]

> mozarc

This kinda has the same problem as servo_arc, though, it is kinda servo/mozilla specific.

Comment 8

[Bobby Holley (:bholley)]

(In reply to Manish Goregaokar [:manishearth] from comment #7)
> > mozarc
> 
> This kinda has the same problem as servo_arc, though, it is kinda
> servo/mozilla specific.

Yes, but that just communicates the state of the world. It's a set of arc stuff that's useful for Mozilla. If somebody wants to add more useful things to it, that's great. But we're not going to consider all consumers equal here, so if there are other consumers that want to take it in a direction that are not compatible with Mozilla's goals, they're going to need to fork it. This would be equally true, just less clear, if we called it Triomphe.

Comment 9

[Manish Goregaokar [:manishearth]]

Oh, to be clear, I'm thinking of the approach where I put it on github as a hard fork, with the intention of making it useful for Rust in general, syncing back if something mozilla-useful comes up :)

If we don't choose that approach it should probably be mozarc.

Comment 10

[Manish Goregaokar [:manishearth]]

Attachment: Bug 1475691: servo_arc cleanups for publishing

Comment 11

[Manish Goregaokar [:manishearth]]

Pushed a bunch of cleanups and doc fixes. My plan is to let these land, perhaps sync with Servo, and then do a fork of more or less the same code (some gecko-specific things removed) as a `triomphe` crate or something. This will be independently maintained as a general-usage FFI Arc utility crate, though I'll try to manually sync any improvements that Gecko may find useful.

I feel like RawOffsetArc should be renamed to just OffsetArc as well, but I don't feel too strongly about that (and it may be better to perform the rename after the fork)

Comment 12

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9009600 [details]
Bug 1475691: servo_arc cleanups for publishing

Emilio Cobos Álvarez (:emilio) has approved the revision.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/12202cbf73b7
servo_arc cleanups for publishing r=emilio

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/88d411b26b2c
Fix tidy issues. r=me
https://hg.mozilla.org/integration/autoland/rev/951aded247b7
Make Servo build. r=me

Comment 15

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/12202cbf73b7
https://hg.mozilla.org/mozilla-central/rev/88d411b26b2c
https://hg.mozilla.org/mozilla-central/rev/951aded247b7