Please add a warning when crate2nix tries to use cargo that's not from nix

[QAston]

When using nix-env and cargo installed from a distro (debian for example) crate2nix generate generates valid, but subtly wrong Cargo.nix files (mostly when it comes to dependency resolution). Please add a warning or error when deteting a non-nix-based cargo, so that people don't spend a couple of days chasing problems which can be easily avoided.

[kolloch]

Thank you for reporting this.

Could you share an example? I guess if the version does not match, there might be problems?

In theory, the version can be mismatched easily, even if both cargo versions came from nix. Maybe the version of the cargo build file (potentially including a hash but which for local installs?) should be checked...

[QAston]

I think the mismatch was something related to the system dependencies used, not just version, but don't have a way to test this anymore. Nix is horrible and I'm very happy I no longer have to use it.

[kolloch]

Okay.

Just a meta note: I was frustrated with nix many times. Still stating "Nix is horrible" in an issue to a project maintained by people, who obviously care about it, is not very constructive and just makes more people unhappy.

Anyways, I also wish it was better in many ways!

[QAston]

@kolloch The biggest problem with nix is that it forks the linux userland without upstreaming the changes, so the binaries built outside of nix can't interact with ones inside nix-shell, which makes the entire nix-shell setup somewhat pointless (unless you put all of your editor tooling inside nix-shell as well, and that means even more forks). Creating a specification for a nix-like dependency resolution that could complement or replace the linux file system hierarchy (FHS) and upstreaming the changes made to individual projects to support this spec would solve this particular issue, simplify nixpkgs, reduce your maintenance burden and overall make me consider nix again.

I had no idea Nix was your fault, I thought you're just making a package for it. Still, that doesn't change my experience with nixpkgs and how much of my work time this packaging system has wasted, and I think it's good that creators know about the issues.

[kolloch]

You new comment seems to at least contain information to start a discussion. Much better than "nix is horrible".

Yet, this is the wrong place to dicuss it. Anyways, all the best to you.

[QAston]

Complaints abut nix were never the core subject of this ticket, just an explanation why I moved on and can no longer reproduce the issue. Closing the issue which still exists doesn't help anybody, but hey, makes tihis particular set of hacks for supporting rust in nix look better than the 5 other sets of hacks to support rust on nix.