When to use crates and when to use external dependencies

While I was looking at Cargo's main.rs, I noticed a comment about using either built in networking support(from a crate) or libcurl, and so I'm a bit confused as to when it makes sense to use a crate for a program and when it makes sense to use an external dependency, I have no idea what the benefits and drawbacks of each are, other than user configuration(like was mentioned in the comment in Cargo's main.rs), is there anything else that should influence the decision on which to depend on?

1 Like

I am missing something obvious. How can you have an "external dependency" that is not a crate ?

Presumably, you're talking about this part of Cargo's initialisation code.

What it looks like is happening here is Cargo selecting between letting libgit2 use its built-in networking support, versus providing it a handle so that it can use libcurl as provided by Cargo itself. This is, presumably, because of differences in features and/or configuration of libgit2 versus curl.

Assuming that's the case, your question doesn't make any sense. libgit2 and libcurl are both external dependencies, and both are linked into Cargo via crates. I might help if you clarify what those words mean to you.

1 Like

No so quite understand what you mentioned.
But there should be a lib crate and at least an executable in your project.
The root crate is defined in src/lib.rs.
The executable is defined in src/main.rs with a main function or src/bin/xx.rs with a main function.
Any other external references should be involved in your lib crate then then the executable can use it.
You executable uses -> your lib crate -> uses external crates

Okay, allow me to rephrase it a bit. If I compile a binary with a libcurl crate, does that binary now have libcurl built into the binary itself or does it now need to me to install libcurl(on a machine that doesn't have it for some reason) in order for that binary to use libcurl and function properly? In what case does a binary need me to install a dependency on my system(or list it in the dependency tree of a package) in order for it to function, and in what case is the dependency included in the compiled binary itself?

I get the impression you're asking for a general answer. There isn't one.

I assume you're talking about curl. Let's start with curl's documentation. It has this:

This crate links to the curl-sys crate which is in turn responsible for acquiring and linking to the libcurl library.

Okay, so on to the curl-sys documentation. It doesn't have any crate-level docs. Alright, what about the curl-sys repository? In the "Building" section of curl-sys' readme, we find:

By default, this crate will attempt to dynamically link to the system-wide libcurl and the system-wide SSL library. Some of this behavior can be customized with various Cargo features:

Further down:

static-curl: Use a bundled libcurl version and statically link to it. Disabled by default.

So there's your answer. Now you just need to repeat this process for every crate you use that links to non-Rust code, and hope it's documented somewhere.

4 Likes

I get the impression you're asking for a general answer

Correct.

Thank you for this answer, it is very helpful. Sorry my initial question wasn't very clear.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.