postprocess has different semantic than anticipated about nlprule HOT 7 CLOSED

Oh sorry, I misunderstood the original issue then. In any case a postprocess function makes sense to reduce the size of the final binary.

Your proposed cache_preprocess function also makes sense. I have to think a bit about the naming, that function would basically transform the buffer to some other buffer immediately after downloading it.

I'm not quite happy with that additional complexity and in general with having to store the binaries in-tree as you do in cargo-spellcheck now but I don't think there's a better solution..

from nlprule.

Actually you don't have to store the binaries in-tree if you just run the build.rs once before cargo publish, right? In that case only the additional complexity is an issue and that's not too bad in the nlprule-build crate.

from nlprule.

I don't think this works. Cargo requires all sources to be part of the git tree and a commit to be able to publish, and that's part of the "deploy when github is down" user story. So while postprocess is nice, I would not want to decompress the files on each run (at least for cargo-spellcheck which is a short lived task, that doesn't seem reasonable).

from nlprule.

I'd be happy to create PR for this!

from nlprule.

That would be great, sure! I think the best solution is a transform function which transforms the binary immediately after downloading / building. It has to be transformed consistently regardless of whether it is built from the build directory or downloaded.

My comment above was perhaps a bit confusing because I conflated the two things (this issue and storing the binaries in-tree), what I meant was that you can just

cargo build # <- creates the nlprule-data directory in your case
cargo publish --allow-dirty

if you didn't want to store the binaries in Git.

from nlprule.

That would be great, sure! I think the best solution is a transform function which transforms the binary immediately after downloading / building. It has to be transformed consistently regardless of whether it is built from the build directory or downloaded.

Good point, noted.

My comment above was perhaps a bit confusing because I conflated the two things (this issue and storing the binaries in-tree), what I meant was that you can just

cargo build # <- creates the nlprule-data directory in your case
cargo publish --allow-dirty

That would work, but it includes the risk of publishing a local state of uncommitted changes which I am not keen on. It seems to be a solution, but not a pretty one.

if you didn't want to store the binaries in Git.

I do :) the user story dependencies should not differ between crates-io and a git based installation (one can also install directly from git with cargo).

from nlprule.

one can also install directly from git with cargo

Oh, that's a good point then. I just thought it's not ideal because it might blow up the size of the repository a bit. So it is enough for me if it is not necessary to store the binaries in-tree when making something that depends on nlprule.

from nlprule.