crate2nix
crate2nix copied to clipboard
nix-community
Master vs Main
Hello, there is an issue where (if a repo uses main instead of master) generatedCargoNix fails. The offending line is here https://github.com/kolloch/crate2nix/blob/master/tools.nix#L237. Unfortunately master is a sensible default given legacy repos, and main is sensible given github's new default naming schema. Perhaps we could allow the user to configure the default branch?
https://github.com/kolloch/crate2nix/pull/206
I think this PR would solve the issue?
Can you try and see if the feat/builtinfetchgit branch of https://github.com/yusdacra/crate2nix fixes the issue?
Also, switching to your branch seems to have resolved this issue https://github.com/kolloch/crate2nix/issues/207
@yusdacra Oh yeah, this worked! Thank you!
That's good to hear. I've been meaning to make a PR for upstream, but that particular branch has so many changes and fixes it's kind of hard to :P
I did also notice this warning. Not sure if its helpful.
trace: warning: crate2nix: Passing `buildRustCrate` as argument to Cargo.nix is deprecated. If you don't customize `buildRustCrate`, replace `callPackage ./Cargo.nix {}` by `import ./Cargo.nix { inherit pkgs; }`, and if you need to customize `buildRustCrate`, use `buildRustCrateForPkgs` instead.
I think it would be very worthwhile to get your branch merged. Especially since crate2nix is looking to release a verion 1.0
There's two branches being discussed here, the PR and the other one. Which is preferred? I am not sure I've encountered tools.nix yet -- so I am not really sure what is going on.
Using master as the name of the default branch was always only a convention and I have encountered varied opinions and alternative conventions in the past. It is not just master vs. main; right now I am working in an organisation that takes the stance: "the tip of the repo contains the latest developments; we call it develop." I've met SVN die-hards that straight up call it trunk. GitHub is leading the charge and setting a new trend with main. The fact is that all are valid and, in this day and age, your likely to encounter a mix of more than just one. Therefore no fallback value will fit all scenarios; it doesn't matter if I can override the fallback value or not (i.e. some repos will need master, others main, yet more others something else!) The fetchGit function is capable of making the decision itself (i.e. ref = null;).
The fetchGit function is capable of making the decision itself (i.e. ref = null;).
Yeah the remote-side HEAD symref is the gold standard here.
What's the recommended workaround? Forking and s/master/HEAD seems to work, but this is rather inelegant.
