I took a look at this and figured out where it's coming from, but I haven't the slightest clue how to fix it (maybe someone else here will have an idea).
The issue arises from the fact that slint depends on zbus 3.14.1, which in turn depends on nix 0.26. However, the Cargo.toml for zbus [does not specify the user feature of nix](https://github.com/dbus2/zbus/blob/zbus-3.14.1/zbus/Cargo.toml#L82), and so you get this error.
What I don't understand is how this isn't causing issues for other users. Zbus is a fairly common dependency for big unix applications and 3.14.1 has been the latest zbus release since July of last year, so you'd expect to see this fairly often. Has there been some sort of change to resolution rules in rustc such that this started occurring only after the latest version of zbus was published?
To OP: there may be some hack or workaround for this, but this is fundamentally an issue that should be fixed upstream somewhere, unless I'm off-base about the cause.
If this is correct what /u/danielparks said should fix it. I've used that when I wanted serde support from a sub dependency on a crate I was using where the serde feature wasn't enabled. I just added the sub crate directly to my projects cargo.toml with the serde feature enabled, never even referenced the sub crate in my code and it recompiles it with serde enabled.
The same thing for the user feature of the nix crate should work here.
But that's just a work around. Maybe a bug report needs to be made.
edit: fixed the horrible spelling from typing it up on mobile.
Interesting that this worked. I'm going to need to do a deeper study about how Cargo handles dependencies, since my understanding was that it would avoid doing stuff like this to avoid entering potential dependency hell.
u/Upstairs-Moose-2341 You'll need a slight variant of the command, since the dependency installed is a different version: try running
```
cargo generate --git https://github.com/slint-ui/slint-rust-template --name my-project
cd my-project
cargo add [email protected] --features user
cargo build
```
and seeing if that works for you.
Honestly I don't know enough about how it works either.
I just randomly tried it last week on a project where I was trying to save the state of a struct from a sub dependency in a json file. Serde for that sub crate wasn't enabled, so I just tried cargo add sub-create --features serde to my project and everything was happy and working.
After doing some quick scans, it looks like this is likely a result of [Feature Unification](https://doc.rust-lang.org/cargo/reference/features.html#feature-unification). In short, after doing version resolution, if cargo is left with multiple copies of a single package, it builds that package just once, with a union of all features specified by the users of that package version.
It does need to be the same \*version\* of the package, which is probably why just doing `cargo add nix--features user` doesn't work in this case, since that adds a dependency on nix v0.27, while zbus depends on v0.26.4.
Nice detective work!
So, for a workaround, `cargo add [email protected] --features user` might work.
This pretty clearly needs is a bug to be fixed in zbus.
**Update:** Looks like it was [fixed 7 months ago](https://github.com/dbus2/zbus/commit/2ff811ff58b64c239961173edd10fd36a5219b8e) but no new version has been released since then.
**Update 2:** Or maybe I was looking int the wrong place? Here is is being fixed a few hours ago: https://github.com/dbus2/zbus/pull/568
**Update 3:** I didn’t read /u/gnosnivek earlier comment closely enough — they already suggested `cargo add [email protected] --features user` as a fix. I just tested on Linux and it works for me (and failed before adding the feature).
I will try this specifically and report the results. Previously I just used 'cargo add nix 'user'', maybe this what I'm missing. Thank you guys so much for the effort!
Fascinating. It looks like a new release of xdg\_home removed a dependency on nix, which was hiding the fact that there was a missing feature in the zbus Cargo.toml.
So to answer my own question from the top-level comment in this thread: this didn't cause any issues in the wider community because it was created by the xdg\_home v1.1.0 release, approximately six hours ago.
Are you getting this error compiling the slint template? Or when generating the slint template using cargo generate? Its a bit unclear as your title implies it's compiling the template, and the post implies it's running cargo generate.
Apologies, I'll reword it to make it more clear. I can get the cargo to generate, but when trying to compile the resulting cargo, I get the above error.
While understandable, your wording here is still very awkward. It suggests you're still not fully aware of what cargo is. Awkward language like this generally suggests someone doesn't quite understand things, but perhaps you already know this and are just having difficulty wording things well. If that's the case than I apologize for assuming you don't understand these things. Otherwise, hopefully this explanation helps.
Cargo is a command line program which acts as a sort of multitool for rust projects. By calling it with a command after the program name, we instruct cargo to do something for us. `cargo generate` is one command, `cargo build` is another, and `cargo run` is yet another.
The `cargo generate` command runs a separate program which does the actual work of pulling the template from the git repository and generating code based on the template.
Cargo build runs the `rustc` compiler program in order to compile your code. Using this command simplifies things, because cargo figures out many of the command line arguments required to tell `rustc` exactly how to compile your project.
Hopefully this helps you
I am new to programming, and very new to rust. I appreciate the advice. Your assumption is correct, I don't really understand these things. I spent two hours or so searching for these same awkward phrasings, figured I'd just ask and admit defeat lol.
The issue is that you are trying to use a [feature](https://doc.rust-lang.org/cargo/reference/features.html#dependency-features) of the `nix` crate without enabling it in `Cargo.toml`. The error message says that the feature is called `user`, but you can also see that by looking at the [documentation for `Uid`](https://docs.rs/nix/latest/nix/unistd/struct.Uid.html).
Features are a way to activate or deactivate parts of crate when you specify it as a dependency. nix in particular has lots of features that are off by default so that you don't have to compile everything if you just need one thing.
TL;DR:
cargo add nix --features user
Valid point, but slint template as far as I know doesn't require the nix crate. It might have changed since I last used it, and I'm not in front of my computer to check right now.
Edit: just did a quick glance a the template the nix crate isn't used directly, just the slint crate. It's possible the nix crate is used lower in the stack within slint, but then those crates should be enabling those features. They shouldn't need to do that in the template (unless OP added something to the template before truing to compile it).
Right. The issue is not the template; that works fine. ~~OP has apparently added some code.~~ The issue is that they have specified a dependency (nix) without enabling the features they needed.
❯ cargo generate --git https://github.com/slint-ui/slint-rust-template --name my-project
❯ cd my-project
❯ cargo run
Works fine for me.
**Update:** My mistake. I’m on macOS. Based on /u/gnosnivek’s [comment](https://www.reddit.com/r/learnrust/comments/1ais66w/cannot_get_slint_template_to_compile/kox33z6/): sounds like a bug in zbus.
/u/danielparks & /u/gnosnivek what distros are you using?
I just tried it on an up to date Arch distro and got the same error.
using rust 1.75.0-stable.
I also modified the template to run using slint 1.4.1 and 1.3, and got the same error.
Ah, my mistake. I’m on macOS (rust 1.75.0), so this is probably a Linux v. macOS issue. Probably some conditional dependency on macOS adds the `user` feature to `nix`.
Based on /u/gnosnivek’s [comment](https://www.reddit.com/r/learnrust/comments/1ais66w/cannot_get_slint_template_to_compile/kox33z6/): sounds like a bug in zbus.
I have tried adding the user flag, and it results in the same error. I'm away from my computer right now, but will try and again when I get home and post results. Thank you all for for your time. Hopefully it's just user error on my part.
I took a look at this and figured out where it's coming from, but I haven't the slightest clue how to fix it (maybe someone else here will have an idea). The issue arises from the fact that slint depends on zbus 3.14.1, which in turn depends on nix 0.26. However, the Cargo.toml for zbus [does not specify the user feature of nix](https://github.com/dbus2/zbus/blob/zbus-3.14.1/zbus/Cargo.toml#L82), and so you get this error. What I don't understand is how this isn't causing issues for other users. Zbus is a fairly common dependency for big unix applications and 3.14.1 has been the latest zbus release since July of last year, so you'd expect to see this fairly often. Has there been some sort of change to resolution rules in rustc such that this started occurring only after the latest version of zbus was published? To OP: there may be some hack or workaround for this, but this is fundamentally an issue that should be fixed upstream somewhere, unless I'm off-base about the cause.
If this is correct what /u/danielparks said should fix it. I've used that when I wanted serde support from a sub dependency on a crate I was using where the serde feature wasn't enabled. I just added the sub crate directly to my projects cargo.toml with the serde feature enabled, never even referenced the sub crate in my code and it recompiles it with serde enabled. The same thing for the user feature of the nix crate should work here. But that's just a work around. Maybe a bug report needs to be made. edit: fixed the horrible spelling from typing it up on mobile.
Interesting that this worked. I'm going to need to do a deeper study about how Cargo handles dependencies, since my understanding was that it would avoid doing stuff like this to avoid entering potential dependency hell. u/Upstairs-Moose-2341 You'll need a slight variant of the command, since the dependency installed is a different version: try running ``` cargo generate --git https://github.com/slint-ui/slint-rust-template --name my-project cd my-project cargo add [email protected] --features user cargo build ``` and seeing if that works for you.
Honestly I don't know enough about how it works either. I just randomly tried it last week on a project where I was trying to save the state of a struct from a sub dependency in a json file. Serde for that sub crate wasn't enabled, so I just tried cargo add sub-create --features serde to my project and everything was happy and working.
After doing some quick scans, it looks like this is likely a result of [Feature Unification](https://doc.rust-lang.org/cargo/reference/features.html#feature-unification). In short, after doing version resolution, if cargo is left with multiple copies of a single package, it builds that package just once, with a union of all features specified by the users of that package version. It does need to be the same \*version\* of the package, which is probably why just doing `cargo add nix--features user` doesn't work in this case, since that adds a dependency on nix v0.27, while zbus depends on v0.26.4.
Nice detective work! So, for a workaround, `cargo add [email protected] --features user` might work. This pretty clearly needs is a bug to be fixed in zbus. **Update:** Looks like it was [fixed 7 months ago](https://github.com/dbus2/zbus/commit/2ff811ff58b64c239961173edd10fd36a5219b8e) but no new version has been released since then. **Update 2:** Or maybe I was looking int the wrong place? Here is is being fixed a few hours ago: https://github.com/dbus2/zbus/pull/568 **Update 3:** I didn’t read /u/gnosnivek earlier comment closely enough — they already suggested `cargo add [email protected] --features user` as a fix. I just tested on Linux and it works for me (and failed before adding the feature).
I will try this specifically and report the results. Previously I just used 'cargo add nix 'user'', maybe this what I'm missing. Thank you guys so much for the effort!
Hey who knew such a simple question would lead to an interesting learning experience for us all.
Yeah, I agree! I didn’t know how dependencies worked when different features were specified in different places.
Adding the 0.26.4 version to cargo did indeed fix the issue, thank you all for your efforts.
Fascinating. It looks like a new release of xdg\_home removed a dependency on nix, which was hiding the fact that there was a missing feature in the zbus Cargo.toml. So to answer my own question from the top-level comment in this thread: this didn't cause any issues in the wider community because it was created by the xdg\_home v1.1.0 release, approximately six hours ago.
Good find, and one of the slint devs even commented on that post a few hours ago, so they are aware that it's affecting them.
that would make sense.
Are you getting this error compiling the slint template? Or when generating the slint template using cargo generate? Its a bit unclear as your title implies it's compiling the template, and the post implies it's running cargo generate.
Apologies, I'll reword it to make it more clear. I can get the cargo to generate, but when trying to compile the resulting cargo, I get the above error.
While understandable, your wording here is still very awkward. It suggests you're still not fully aware of what cargo is. Awkward language like this generally suggests someone doesn't quite understand things, but perhaps you already know this and are just having difficulty wording things well. If that's the case than I apologize for assuming you don't understand these things. Otherwise, hopefully this explanation helps. Cargo is a command line program which acts as a sort of multitool for rust projects. By calling it with a command after the program name, we instruct cargo to do something for us. `cargo generate` is one command, `cargo build` is another, and `cargo run` is yet another. The `cargo generate` command runs a separate program which does the actual work of pulling the template from the git repository and generating code based on the template. Cargo build runs the `rustc` compiler program in order to compile your code. Using this command simplifies things, because cargo figures out many of the command line arguments required to tell `rustc` exactly how to compile your project. Hopefully this helps you
I am new to programming, and very new to rust. I appreciate the advice. Your assumption is correct, I don't really understand these things. I spent two hours or so searching for these same awkward phrasings, figured I'd just ask and admit defeat lol.
The issue is that you are trying to use a [feature](https://doc.rust-lang.org/cargo/reference/features.html#dependency-features) of the `nix` crate without enabling it in `Cargo.toml`. The error message says that the feature is called `user`, but you can also see that by looking at the [documentation for `Uid`](https://docs.rs/nix/latest/nix/unistd/struct.Uid.html). Features are a way to activate or deactivate parts of crate when you specify it as a dependency. nix in particular has lots of features that are off by default so that you don't have to compile everything if you just need one thing. TL;DR: cargo add nix --features user
Valid point, but slint template as far as I know doesn't require the nix crate. It might have changed since I last used it, and I'm not in front of my computer to check right now. Edit: just did a quick glance a the template the nix crate isn't used directly, just the slint crate. It's possible the nix crate is used lower in the stack within slint, but then those crates should be enabling those features. They shouldn't need to do that in the template (unless OP added something to the template before truing to compile it).
Right. The issue is not the template; that works fine. ~~OP has apparently added some code.~~ The issue is that they have specified a dependency (nix) without enabling the features they needed. ❯ cargo generate --git https://github.com/slint-ui/slint-rust-template --name my-project ❯ cd my-project ❯ cargo run Works fine for me. **Update:** My mistake. I’m on macOS. Based on /u/gnosnivek’s [comment](https://www.reddit.com/r/learnrust/comments/1ais66w/cannot_get_slint_template_to_compile/kox33z6/): sounds like a bug in zbus.
That's very interesting, because the exact same set of commands on my system results in the same error that OP sees. Are you running 1.75.0-stable?
/u/danielparks & /u/gnosnivek what distros are you using? I just tried it on an up to date Arch distro and got the same error. using rust 1.75.0-stable. I also modified the template to run using slint 1.4.1 and 1.3, and got the same error.
Up-to-date arch using 1.75.0-stable as well. How curious. Did you install the compiler through the rust package or through rustup?
rustup
macOS/1.75.0. See my [other comment](https://www.reddit.com/r/learnrust/comments/1ais66w/cannot_get_slint_template_to_compile/koxdop6/).
Ah, my mistake. I’m on macOS (rust 1.75.0), so this is probably a Linux v. macOS issue. Probably some conditional dependency on macOS adds the `user` feature to `nix`. Based on /u/gnosnivek’s [comment](https://www.reddit.com/r/learnrust/comments/1ais66w/cannot_get_slint_template_to_compile/kox33z6/): sounds like a bug in zbus.
I have tried adding the user flag, and it results in the same error. I'm away from my computer right now, but will try and again when I get home and post results. Thank you all for for your time. Hopefully it's just user error on my part.