You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was working on packaging this crate to include it to Debian. It will be a dependency of something else there. The crate builds and works just fine, but the test fails and it is nice thing to have working tests under Debian Rust packaging infrastructure.
This line includes the source code of the tool itself into the test. Under normal circumstances include_dir is a subcrate of a workspace. This means the target directory resided outside of it's directory, level up.
Under debian the package is fetched from the crates.io, so it ends up being a top directory of itself. For this reason the test attempts to include target directory, which somehow overwhelms the include_dir (maybe it is size, maybe it is a race condition), but the file under test src/main.rs does not get included. Same about the extraction test.
I just wanted to let you know about this and ask if you'd be willing to fix this. Or alternatively accept a PR with the fix, I can work on that. In the case of latter, should I try to find the solution on my own, or do you have some advice on would would be a preferrable fix? If I were to work on the PR I'd probably include a dedicated tests/testdata subdirectory with a few files and subdirectories.
Thanks,
Igor.
The text was updated successfully, but these errors were encountered:
igor-petruk
changed the title
include_dir integration test fails when built under Debian packaging infrastructure.
include_dir integration test fails when built under the Debian packaging infrastructure.
Jan 9, 2023
I'm not sure why certain files aren't being included as expected. Normally if you include a very large directory tree containing a lot of data (e.g. target/), it'll cause the Rust compiler to OOM when expanding the proc macro, but I've never heard of files going missing.
Could it be that the way Debian fetches files (i.e. not doing a git clone of the whole repo) causes certain files to not be downloaded or to be in a different folder?
I guess one way to test that would be to modify the test to list all included files the run cargo build && cargo test with $CARGO_TARGET_DIR set to some other location. That way you can see exactly what was included and whether things are in the location you would expect, rather than being one directory up or down.
Hi,
I was working on packaging this crate to include it to Debian. It will be a dependency of something else there. The crate builds and works just fine, but the test fails and it is nice thing to have working tests under Debian Rust packaging infrastructure.
The root cause is very interesting: https://github.com/Michael-F-Bryan/include_dir/blob/master/include_dir/tests/integration_test.rs#L5
This line includes the source code of the tool itself into the test. Under normal circumstances
include_dir
is a subcrate of a workspace. This means thetarget
directory resided outside of it's directory, level up.Under debian the package is fetched from the crates.io, so it ends up being a top directory of itself. For this reason the test attempts to include
target
directory, which somehow overwhelms theinclude_dir
(maybe it is size, maybe it is a race condition), but the file under testsrc/main.rs
does not get included. Same about the extraction test.I just wanted to let you know about this and ask if you'd be willing to fix this. Or alternatively accept a PR with the fix, I can work on that. In the case of latter, should I try to find the solution on my own, or do you have some advice on would would be a preferrable fix? If I were to work on the PR I'd probably include a dedicated
tests/testdata
subdirectory with a few files and subdirectories.Thanks,
Igor.
The text was updated successfully, but these errors were encountered: