Dependency management

[robinkrahl]

Before I comment on the issue, I’d like to know your goals for dependency management. My guess is that you are including the dependencies in the nitrocli repository to ensure that cargo does not download unsigned and unverified code from third parties. Is that correct?

[d-e-s-o]

Yeah, it's less about not trusting cargo (crates are checksummed and I trust it to verify those) and more about the ability to compile a project without internet access. I understand cargo supports caching and separate registries but not all of that has been available or working properly since the beginning. It also helps get an overview of the size of dependencies you rely on and makes it very obvious what changed between versions when upgrading.

That being said, if you are opposed to that or find it to be a hinderance for whatever reason, we can discuss moving to a more standard model.

[robinkrahl]

Okay, I see. I’m not strongly opposed to the current model, but I do see some downsides. This model tends to use outdated software. For example, currently cc, libc and pkg-config are outdated. Also, mixing the project code with the dependencies makes the project repository a bit confusing, and the effort to update the dependencies is quite high.

An easier solution (at least for offline compilation) might be to automatically generate this bundle for every release and provide it as a tarball. But I’ll also have another look at the other options Rust provides (especially vendoring).

[d-e-s-o]

Okay, I see. I’m not strongly opposed to the current model, but I do see some downsides. This model tends to use outdated software. For example, currently cc, libc and pkg-config are outdated.

They are outdated because I did not update them :)

cargo generally pins dependencies and so unless you explicitly update them they will eventually be outdated. That is especially true for applications, as they generally package a Cargo.lock file as part of the source distribution.

Also, mixing the project code with the dependencies makes the project repository a bit confusing, and the effort to update the dependencies is quite high.

I am using git-subrepo for the "management" and ultimately the upgrade is just one more command invocation from what I can tell.

An easier solution (at least for offline compilation) might be to automatically generate this bundle for every release and provide it as a tarball. But I’ll also have another look at the other options Rust provides (especially vendoring).

Yeah, but that would mainly work on a per-release basis. My objective was to have a more general solution that works for every commit.

I believe cargo-vendor is a cargo based solution for source code vendoring. It came after git-subrepo from what I can tell and, obviously, is cargo specific.

[robinkrahl]

They are outdated because I did not update them :)

cargo generally pins dependencies and so unless you explicitly update them they will eventually be outdated. That is especially true for applications, as they generally package a Cargo.lock file as part of the source distribution.

The Cargo.lock used to be removed by crates.io, but it seems that was changed recently. But still it’s easier to run cargo update than to update all downloaded dependencies (at least for users that are not familiar with this model).

I am using git-subrepo for the "management" and ultimately the upgrade is just one more command invocation from what I can tell.

I’ll have a look at it! I think I’m just a bit reluctant to use a non-standard solution without a clear use case (or maybe I’m missing something).

[d-e-s-o]

I am using git-subrepo for the "management" and ultimately the upgrade is just one more command invocation from what I can tell.

I’ll have a look at it! I think I’m just a bit reluctant to use a non-standard solution without a clear use case (or maybe I’m missing something).

Sure! I was just stating what I was doing, not saying you have to use it :)

[robinkrahl]

All questions have been answered. :-)