Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot generate the with_problematic_crates Cargo.nix sample #36

Closed
nlewo opened this issue Oct 14, 2019 · 3 comments · Fixed by #58
Closed

Cannot generate the with_problematic_crates Cargo.nix sample #36

nlewo opened this issue Oct 14, 2019 · 3 comments · Fixed by #58

Comments

@nlewo
Copy link
Member

nlewo commented Oct 14, 2019

I'm trying to (re)generate the Cargo.nix file from the sample project with_problematic_crates but my crate2nix doesn't generate the same file (libPath attributes are missing for instance)

Here are the commands I executed:

[lewo@tilia:~/repos/crate2nix]$ git log -n1 --oneline 
277fe73 (HEAD -> master, origin/master) Fix #23 - Move integration tests into nix

[lewo@tilia:~/repos/crate2nix]$ nix-shell
crate2nix 0.6.0-alpha.0
Peter Kolloch <info@eigenvalue.net>
Nix build file generator for a cargo rust projects.

USAGE:
    crate2nix <SUBCOMMAND>

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

SUBCOMMANDS:
    completions    Generate auto-completions for the shell.
    generate       Generate a nix file from a cargo rust project.
    help           Prints this message or the help of the given subcommand(s)

[nix-shell:~/repos/crate2nix]$ crate2nix "generate" "-f" "sample_projects/with_problematic_crates/Cargo.toml" "-o" "sample_projects/with_problematic_crates/Cargo.nix"
Generated sample_projects/with_problematic_crates/Cargo.nix successfully.

[nix-shell:~/repos/crate2nix]$ git diff -- sample_projects/with_problematic_crates/Cargo.nix | grep libPath
-        libPath = "cloudabi.rs";
-        libPath = "lib.rs";
-        libPath = "lib.rs";
-        libPath = "lib.rs";
-        libPath = "lib.rs";
-        libPath = "lib.rs";
-        libPath = "lib.rs";
-        libPath = "index_tests.rs";
-        libPath = "lib.rs";
-        libPath = "lib.rs";
-        libPath = "lib.rs";
-        libPath = "lib.rs";
-        libPath = "lib.rs";
-        libPath = "lib.rs";
-        libPath = "lib.rs";
-        libPath = "lib.rs";
-        libPath = "lib.rs";
-        libPath = "src/untrusted.rs";

[nix-shell:~/repos/crate2nix]$ 

The Cargo.nix file I generated: nlewo@047ae1d#diff-d44232a1e2e6e2b12c8e1ef2226078bc

Did I miss something or is it an real issue?

@kolloch
Copy link
Collaborator

kolloch commented Oct 22, 2019

Hmm, good question.

So, unfortunately, the cargo metadata command generates "opaque package IDs" which include local directory paths (see known issues in README). So these changes are expected.

The rest are not. Especially the libPath = "lib.rs" things should not be added since e2a0cc6, I guess?

In general, some of the changes could be explained by a cargo update but I did not see changes in the Cargo.lock file. I would hope that cargo produces reproducible output for cargo metadata with a given lockfile (except the packe ID problem).

@kolloch
Copy link
Collaborator

kolloch commented Oct 31, 2019

Any ideas how to follow up on this?

@kolloch
Copy link
Collaborator

kolloch commented Nov 24, 2019

Maybe you can try executing the "./regenerate_cargo_nix.sh"

@kolloch kolloch closed this as completed Nov 24, 2019
nlewo added a commit to nlewo/crate2nix that referenced this issue Dec 3, 2019
When the ~/.cargo directory is symlinked, the `target.src_path` needs to
be canonicalized to be able to strip the prefix (`package_path`), which has already
been canonicalized.

Suppose `~/.cargo` is a symlinked to `/mnt/cargo`:
- if `target.src_path` is something such as `/home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/winreg-0.6.2`
- `package_path` would be something such as `/mnt/.cargo/registry/src/github.com-1ecc6299db9ec823/winreg-0.6.2`

Since `package_path` is not a prefix of `target.src_path`,
`strip_prefix` returns an error and no `libPath` attribute are
created.

fix nix-community#36
nlewo added a commit to nlewo/crate2nix that referenced this issue Dec 3, 2019
When the ~/.cargo directory is symlinked, the `target.src_path` needs
to be canonicalized to be able to strip the prefix (`package_path`),
since it has already been canonicalized.

Suppose `/home/user/.cargo` is a symlinked to `/mnt/.cargo`:
- if `target.src_path` is something such as      `/home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/winreg-0.6.2`
- then `package_path` would be something such as `/mnt/.cargo/registry/src/github.com-1ecc6299db9ec823/winreg-0.6.2`

In this scenario, since `package_path` is not a prefix of
`target.src_path`, `strip_prefix` returns an error and no `libPath`
attribute are created.

Fixes nix-community#36
nlewo added a commit to nlewo/crate2nix that referenced this issue Dec 3, 2019
When the ~/.cargo directory is symlinked, the `target.src_path` needs
to be canonicalized to be able to strip the prefix (`package_path`),
since it has already been canonicalized.

Suppose `/home/user/.cargo` is a symlinked to `/mnt/.cargo`:
- if `target.src_path` is something such as      `/home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/winreg-0.6.2`
- then `package_path` would be something such as `/mnt/.cargo/registry/src/github.com-1ecc6299db9ec823/winreg-0.6.2`

In this scenario, since `package_path` is not a prefix of
`target.src_path`, `strip_prefix` returns an error and no `libPath`
attribute are created.

Fixes nix-community#36
nlewo added a commit to nlewo/crate2nix that referenced this issue Dec 3, 2019
When the ~/.cargo directory is symlinked, the `target.src_path` needs
to be canonicalized to be able to strip the prefix (`package_path`),
since it has already been canonicalized.

Suppose `/home/user/.cargo` is a symlink to `/mnt/.cargo`:
- if `target.src_path` is something such as      `/home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/winreg-0.6.2`
- then `package_path` would be something such as `/mnt/.cargo/registry/src/github.com-1ecc6299db9ec823/winreg-0.6.2`

In this scenario, since `package_path` is not a prefix of
`target.src_path`, `strip_prefix` returns an error and no `libPath`
attribute are created.

Fixes nix-community#36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants