#cargo

/

      • acrichto
        it doesn't build them, it just resolves them
      • steveklabnik
        ignatenkobrain: dunno if you know but debian has built
      • ignatenkobrain
        bennofs: so it will propagate deps to the current building package
      • steveklabnik
        !crate debcargo
      • rustbot
        debcargo (1.3.0) - Create a Debian package from a Cargo crate. -> https://crates.io/crates/debcargo <https://docs.rs/debcargo>;
      • steveklabnik
        no idea if that's helpful or not
      • but wanted to mention it
      • acrichto
        ignatenkobrain: so "not including dev deps" is a non-starter for `cargo build`
      • maybe an option could be passed or something like that, but it's a radical change from the current behavior
      • ignatenkobrain: would a possible solution to just be run `cargo vendor` (or the equivalent) ahead of time?
      • and then running tests?
      • that will ensure that all dependencies are in the registry to correctly resolve the crate graph
      • ignatenkobrain
        acrichto: what means ahead of time?
      • before real build?
      • bennofs
        ignatenkobrain: the approach I was describing would not require any "propagation" at all. rust executable projects would not depend on libraries, but instead just vendor the source code of the library
      • ignatenkobrain
        bennofs: well, I said why I don't like cargo-vendor approach
      • acrichto
        ignatenkobrain: yeah
      • ignatenkobrain
        acrichto: it's impossible =(
      • because you still don't have those deps in local registry
      • and it should not access network
      • acrichto
        well...
      • so that's the dependency graph
      • can that not be expressed?
      • ignatenkobrain doesn't get it
      • bennofs
        acrichto: the problem is that RPM does not have a dev/non-dev distinction (I believe) so all dev-dependencies are also non-dev deps automatically which leads to a cycle
      • ignatenkobrain
        bennofs: nope, u're wrong
      • bennofs
        acrichto: you can break this cycle by explictly constructing an untested package
      • ignatenkobrain
        I mean you are right to some degree
      • but now there's different problem
      • bennofs
        acrichto: but cargo does not support the idea of building an "untested" version of a package
      • acrichto
        ignatenkobrain: so if you'd like to generate a lock file for a crate (e.g. cargo build or cargo test), then that depends on dependencies and dev-dependencies
      • bennofs
        (that's my understanding of the issue)
      • acrichto
        ignatenkobrain: that's how cargo operates today
      • ignatenkobrain: is that not able to be expressed with fedora?
      • bennofs
        acrichto: I think in this case it's about rust libraries, so no lockfile
      • ignatenkobrain
        acrichto: so you want to generate Cargo.lock before build?
      • acrichto
        bennofs: that's not true, let's not jump to conclusions so quickly
      • the build recipe ignatenkobrain gisted involved a literal `cargo build`
      • and yes, Cargo always generates a lockfile when invoked
      • bennofs
        acrichto: yes, but the lockfile is not in the source distribution
      • acrichto
        correct, that's akin to saying the precise dependency graph is not in the source distribution
      • which is "correct"
      • the dependency graph needs to be resolved at build time
      • and that's what Cargo.lock represents, a single resolution of the dependency graph
      • ignatenkobrain
        acrichto: for me it would work if I can turn off dependency resolution at all D:
      • because all dependencies are mirrored in RPMs
      • bennofs
        acrichto: ah i think i see what you're saying. you meant that it would be weird if cargo needed to re-resolve the dep graph if you later decide to build tests as well
      • acrichto
        ignatenkobrain: so this is where it's getting into a much broader discussion
      • ignatenkobrain: we can't really on a whim just add that to cargo, it's a serious change in behavior
      • it's possible to add, don't get me wrong (others would also find it useful I believe)
      • but we can't just whip it up and throw it in
      • ignatenkobrain
        acrichto: why not just add support for `--nodeps` for cargo-build/test/install ?
      • bennofs
        acrichto: well, it can be very easily added: just build the library "as-if" it was required by another library :)
      • ignatenkobrain
        like we have for cargo metadata
      • acrichto
        bennofs: for normal usage, yes, we don't want the dependency graph (Cargo.lock) changing when you switch between build/test
      • ignatenkobrain: that statement taken in isolation makes no sense, there's an entire RFC behind that statement which details how cargo will actually operate
      • bennofs
        acrichto: how about adding a new command, cargo build-verify, that checks if you will be able to build dependent packages against this library?
      • acrichto: this command would only be useful for package managers
      • name up to debate ofc
      • ignatenkobrain
        bennofs: that will not help as well
      • because for binaries
      • imagine, oxipng
      • it's bin + lib
      • bennofs
        ignatenkobrain: you cannot have recursive dependencies for binaries, can you?
      • oh...
      • italic has quit
      • ignatenkobrain
        so if I disable tests (in terms of RPM)
      • it will not bring some deps
      • and cargo build will fail
      • because dev-deps don't exist
      • so build-verify would solve thing for librarries, but not for binaries
      • bennofs
        oh
      • right
      • ignatenkobrain
        BuildRequires: (crate(zopfli) >= 0.3.4 with crate(zopfli) < 0.4.0)
      • %if %{with check}
      • BuildRequires: ((crate(image) >= 0.12.0 with crate(image) < 0.13.0) with crate(image/png_codec))
      • %endif
      • so cargo build/install will fail if `image` is not in registry
      • bennofs
        ignatenkobrain: and image depends on oxipng?
      • ignatenkobrain
        bennofs: nope
      • it's just some crate which I don't have in buildroot
      • but this is always the case for cyclic dependencies
      • that I have first to bootstrap thing without tests
      • then I bootstrap other things without tests
      • and then rebootstrap again everything with tests
      • it's all about dev-dependencies
      • # regex-syntax -> quickcheck(dev) -> env_logger -> regex(opt) -> regex-syntax
      • so first I build regex-syntax without cargo test (but with build)
      • bennofs
        ignatenkobrain: hmm. perhaps what you really need is some kind of "dry build"?
      • ignatenkobrain: like, in the bootstrap phase, you don't need to generate any binaries/libraries objects anyway
      • ignatenkobrain
        bennofs: no, I need normal build, but it should not look into dev-deps ;)
      • bennofs
        oh I keep forgetting about binary dependencies
      • ignatenkobrain
        if I don't execute cargo test, I don't have those crates in my registry
      • if I don't have those crates in my registry cargo-build/install complain
      • even cargo doesn't use them
      • sorry guys, I have to leave... Hopefully you got my problem right ;)
      • bennofs
        ignatenkobrain: well, you don't save the build outputs anyway, right?
      • ignatenkobrain
        I will read backlog when will get back
      • bennofs: for libs -- no, for bins -- yes
      • bennofs
        ignatenkobrain: so a build that produces no build outputs would be fine for bootstrap, correct?
      • ignatenkobrain
        when bin have tests and I say "do not test it" it fails
      • just because cargo can't resolve deps
      • bennofs
        i understand what happens. just thinking about alternative solutions
      • at least i think so :)
      • ignatenkobrain-M joined the channel
      • ytain joined the channel