Use TOML serializer from nixpkgs #300
Conversation
Patryk27
force-pushed
the
fix-263/to-toml
branch
from
1568234
to
8b09936
Compare
|
I've rebased just now.
Yeah, the older version in nixpkgs was kinda bad (e.g. didn't support stuff like |
|
Ouch, something's failing on the CI - I'll take a look later 🤨 |
|
Alright, the issue is that older nixpkgs' (< 23) I've adjusted the logic to use our custom serializer (as it was) for older nixpkgs and rely on the nixpkgs' serializer only when nixpkgs are recent enough, with the intention of getting rid of our custom serializer when nixpkgs v23+ get more widely adopted. |
|
Huh, it's still failing, but the tests succeed on my Linux machine 🤨 -- lemme check on another one |
|
Alrighty, done! |
|
hmm, analyzing failing tests 🔍 |
|
Alright, got it! I think #299 caused us to (randomly) bump into rust-lang/cargo#11188 where tl;dr it looks like when both crates.io & Git dependencies are packed together, as we do now: Line 91 in d9a33d6 ... Cargo (sometimes, randomly) decides that Git-based dependencies must have checksums specified, which we don't do for them, since we don't know that checksum: Line 466 in d9a33d6 Creating two separate sources (one for crates.io and one for Git dependencies), as I've done in the recent commit just now, seems to avoid the issue (I've checked on aarch64-darwin, x86_64-linux NixOS + x86_64-linux Ubuntu, and everything passed on the first time now). |
Before #300, our `builtinz.toTOML` used to return a string representing the serialized document which was later redirected into a file: https://github.com/nix-community/naersk/pull/300/files#diff-b6b537316f2d29c8faf178a110366796811d1bc72f694262c7d2efad79aa984bL238 Over that merge request, this was changed to return a path, to make it consistent with how nixpkgs' formatters works, but I haven't noticed one place that still _read_ the file instead of returning a path (which was fine before, since the code did `echo ... > ...`, but currently the code does `cp`). Closes #305.
Before #300, our `builtinz.toTOML` used to return a string representing the serialized document which was later redirected into a file: https://github.com/nix-community/naersk/pull/300/files#diff-b6b537316f2d29c8faf178a110366796811d1bc72f694262c7d2efad79aa984bL238 Over that merge request, this was changed to return a path, to make it consistent with how nixpkgs' formatters work - but I haven't noticed one place that still _read_ the file instead of returning a path (which was fine before, since the code did `echo ... > ...`, but is not a correct thing to do for `cp`). Closes #305.
Before #300, our `builtinz.toTOML` used to return a string representing the serialized document which was later redirected into a file: https://github.com/nix-community/naersk/pull/300/files#diff-b6b537316f2d29c8faf178a110366796811d1bc72f694262c7d2efad79aa984bL238 Over that merge request, this was changed to return a path, to make it consistent with how nixpkgs' formatters work - but I haven't noticed one place that still _read_ the file instead of returning a path (which was fine before, since the code did `echo ... > ...`, but is not a correct thing to do for `cp`). Closes #305.
Before #300, our `builtinz.toTOML` used to return a string representing the serialized document which was later redirected into a file: https://github.com/nix-community/naersk/pull/300/files#diff-b6b537316f2d29c8faf178a110366796811d1bc72f694262c7d2efad79aa984bL238 Over that merge request, this was changed to return a path, to make it consistent with how nixpkgs' formatters work - but I haven't noticed one place that still _read_ the file instead of returning a path (which was fine before, since the code did `echo ... > ...`, but is not a correct thing to do for `cp`). Closes #305.
Before #300, our `builtinz.toTOML` used to return a string representing the serialized document which was later redirected into a file: https://github.com/nix-community/naersk/pull/300/files#diff-b6b537316f2d29c8faf178a110366796811d1bc72f694262c7d2efad79aa984bL238 Over that merge request, this was changed to return a path, to make it consistent with how nixpkgs' formatters work - but I haven't noticed one place that still _read_ the file instead of returning a path (which was fine before, since the code did `echo ... > ...`, but is not a correct thing to do for `cp`). Closes #305.
Requires #288.
Closes #263.