Why are glium/winit/etc no longer re-exported?

[pedrocr]

Having gone through the (reasonably simple) work of going from conrod 0.61 and 0.65 with the new packaging setup here are a couple of notes.

First it may make sense to add a warning to the conrod crate explaining that it's no longer to be used. I was convinced I was using the latest conrod until I realized the crate names had changed.

Second, the previous packaging allowed for things like:

use conrod::backend::glium::glium::texture::srgb_texture2d::SrgbTexture2d;

which means I only needed to depend on conrod and then ended up using whichever glium and winit versions it depended on. Now I need to depend on glium and winit explicitely and when the versions don't match the compile fails. So I'm still limited to using whichever glium/winit versions conrod is depending on but now I need to figure out what those are to specify them explicitly to cargo. Is there a better way to do this instead?

[mitchmindtree]

First it may make sense to add a warning to the conrod crate explaining that it's no longer to be used.

Thanks for the suggestion, do you have a recommended way of going about doing this?

Now I need to depend on glium and winit explicitely and when the versions don't match the compile fails

Now I need to depend on glium and winit explicitely and when the versions don't match the compile fails. So I'm still limited to using whichever glium/winit versions conrod is depending on but now I need to figure out what those are to specify them explicitly to cargo. Is there a better way to do this instead?

You can read more about the reasons behind the refactor away from features towards backend crates at #1223.

You can also read more about why winit is no longer re-exported at #1262.

W.r.t. keeping up with versions, I understand your pain, but I hope you can understand how difficult this has been to maintain in conrod. As a result of re-exporting winit, I had to also ensure that the gfx, glium and vulkano backends were all compatible with whatever the latest version of winit was before I could ever update winit. This frequently meant I would have to go to those repositories, contribute the necessary breaking changes, wait days for them to merge the PR and wait even longer for them to publish a release in the hope that eventually each of the backends would sync up. I already have very little time to maintain conrod - #1223 and #1262 have been essential for me to maintain the ability to update each backend as necessary without also having to try and synchronize them all upstream myself.

I hope this and the linked PRs helped to explain the motivation behind these changes! Feel free to re-open this issue if you feel this hasn't been properly addressed!

[pedrocr]

First, thanks a lot for all the work on conrod. It's a great contribution to the rust ecosystem, and a great experiment with the immediate vs retained mix.

Thanks for the suggestion, do you have a recommended way of going about doing this?

My guess would be to just push a 0.61.2 conrod crate that is exactly the same except for README.md explaining that the new crates should be used.

W.r.t. keeping up with versions, I understand your pain, but I hope you can understand how difficult this has been to maintain in conrod. As a result of re-exporting winit, I had to also ensure that the gfx, glium and vulkano backends were all compatible with whatever the latest version of winit was before I could ever update winit.

I've read the references but am missing something about the problem. My current issue is that my Cargo.toml adds conrod like this:

conrod_core = "0.65"
conrod_glium = "0.65"
conrod_winit = "0.65"
glium = "0.25"
winit = "0.18"

The glium and winit dependencies were specified to be the same as what's in conrod_glium and conrod_winit. If they're not the compile fails. For example if I update winit to 0.19 I get this:

error[E0308]: mismatched types
   --> src/frontend/window.rs:176:46
    |
176 |           if let Some(event) = convert_event(event.clone(), &GliumDisplayWinitWrapper(display)) {
    |                                              ^^^^^^^^^^^^^ expected enum `winit::Event`, found enum `frontend::window::glium::glutin::Event`
    |
    = note: expected type `winit::Event`
               found type `frontend::window::glium::glutin::Event`
note: Perhaps two different versions of crate `winit` are being used?
   --> src/frontend/window.rs:176:46
    |
176 |           if let Some(event) = convert_event(event.clone(), &GliumDisplayWinitWrapper(display)) {
    |  

(see the hint about two different versions of the crate).

This is even brittle as I suppose a 0.65 point release could update winit/glium and break the build. All I want to do is in the code write "use whatever glium/winit conrod has already pulled in".

Is there really extra maintenance in just reexporting winit in conrod_winit and glium in conrod_glium?

[pedrocr]

As another example, to update to conrod 0.66 my diff is:

diff --git a/Cargo.toml b/Cargo.toml
index 7399f59..fd2dd02 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -12,11 +12,11 @@ categories = ["multimedia::images"]
 image = "0.21"
 rand = "0.6"
 crossbeam-utils = "0.6"
-conrod_core = "0.65"
-conrod_glium = "0.65"
-conrod_winit = "0.65"
-glium = "0.23"
-winit = "0.18"
+conrod_core = "0.66"
+conrod_glium = "0.66"
+conrod_winit = "0.66"
+glium = "0.24"
+winit = "0.19"

This required figuring out 0.24 and 0.19 were the correct glium/winit versions before it would compile again.

[mitchmindtree]

Is there really extra maintenance in just reexporting winit in conrod_winit

Yes, because users who require using a different version of winit in order to be compatible with say conrod_gfx or conrod_vulkano (e.g. because their support happens to be one version ahead or behind) will complain because they now have to import two versions of winit, one of which is completely unused. These users will also likely be even more confused as they will think something is wrong with their code if e.g. the version of winit re-exported in conrod_winit does not match the version compatible with the back-end they're trying to use. This is what I hoped to make clear in #1262.

I will accept a PR to have glium re-exported from conrod_glium because it is the only back-end in which glium might be used.

Again, I'm sorry that you have to check the compatible versions for winit, glium, and the associated conrod_* crates, but this short inconvenience is easily worth the maintenance burden that has been lifted from me in trying to synchronise all the upstream crates just so that we can make sure the re-exported version of winit is compatible with all backends. I hope this helps to clarify things a little!

[pedrocr]

Yes, because users who require using a different version of winit in order to be compatible with say conrod_gfx or conrod_vulkano (e.g. because their support happens to be one version ahead or behind) will complain because they now have to import two versions of winit, one of which is completely unused.

I guess what was unclear to me was what was actually bringing in winit as a dependency from conrod. Right now depending on conrod_core+conrod_glium+conrod_winit brings in a winit version that will then be incompatible with other versions. If that didn't happen the current design would make more sense to me as you could use any version of winit you wanted. Looking into it it seems what's happening is conrod_glium->glium->glutin->winit.

I will accept a PR to have glium re-exported from conrod_glium because it is the only back-end in which glium might be used.

If glium was reexported, and if glium would then reexport winit, this would fix it. And the other backends could do the same I suppose. If their dependencies bring in winit they could reexport those. I don't think this happens generally though so there's not much point. Maybe cargo needs a way to specificy a dependency versioned as "whatever crate X has already dragged in".

Again, I'm sorry that you have to check the compatible versions for winit, glium, and the associated conrod_* crates

Don't worry about this at all. I only discussed this to try and help. If it does indeed bring an extra burden by all means just keep it as is. One day when the ecosystem is much more stable this won't be a problem.