Reduce the number of crates library users need to care about

[pcwalton]

Right now we have a lot of crates, and this is causing friction for potential library users. One option would be to have a super-crate that reexports everything important. But I worry this crate will grow without limit. We already have Pathfinder native API, canvas, SVG, PDF, SWF, and Lottie frontends and it's unlikely a user will care about all of them. Likewise with GPU API backends: we already have OpenGL, WebGL, and Metal backends and will possibly get Vulkan, DX11, DX12, and gfx-rs backends in the future; it's unlikely a user wants to run on all of these platforms.

I think perhaps we could have the "front-end" crates—pathfinder_canvas and pathfinder_svg—reexport the functionality necessary to use them. Then you'd only need to import two crates in most cases: the front-end (pathfinder_canvas/pathfinder_svg) and a GPU backend (pathfinder_gl, etc.) Another option would be to have a front-end pathfinder_vg crate that reexports all the subcrates behind feature flags. (Unfortunately it can't be named just pathfinder because that name is already in use on crates.io.)

Other suggestions and ideas are very welcome.

[BurntCaramel]

I really like the front-end / back-end crates, because then it’s easy to know as a user explicitly which platforms you are supporting. I can also imagine the associated docs being very obvious and easy to follow: “I want canvas, and I want to support OpenGL and Metal, so I install pathfinder_X”

Does reexporting add any overhead?

[pcwalton]

It shouldn't add any overhead, no.

[s3bk]

I like the reexport everything behind feature flags.

[nox]

I would rather people depend on whatever crate they want to use than use an umbrella crate with one feature per backend.

[nox]

Having a big umbrella crate means that your Cargo.lock is full of things you don't actually use, which is confusing when reading the lock file (yes, sometimes you do need to do that), or when using tools such as cargo fetch (I've already seen that command download crates that I didn't need, but maybe I misread).

[kentfredric]

Also, although I like the appeal for the cargo oriented user audience, I dislike the umbrella-crate proxy pattern as a Linux Vendor. Mostly, because it just creates more busywork for us, it just adds more points of failure, and, (this is the worst part): You can't treat the umbrella crate dependencies optionally, you have to handle all of them anyway (I even have to handle test dependencies, and optional test dependencies).

So directly depending on what you want IME, is better.

[nb: I speak on behalf of Gentoo, so my opinion may seem selective, but I also converse with debian folk and people who work on this sort of thing in a few vendors, so its not entirely unique an opinion I'm channeling here, just some of it may be more mine than theirs]

[pcwalton]

I think we're going to hold off on this for now, per feedback. Closing for now, but may reopen in the future if this decision changes.