Automatically detect dependencies

[Rufflewind]

For one-off scripts, it'd be a little more convenient to avoid having to write dependencies twice. Once for the // cargo-deps:, and another for extern crate. Could it perhaps infer // cargo-deps: from extern crate?

If the name has an underscore (which may or may not be a hyphen), then it could get the canonical name from crates.io.

[bluss]

Note that dependencies use package names and extern crate crate names, they can differ by more than just the hyphen.

[DanielKeep]

Sorry for taking so long to respond to this.

There are numerous problems with this:

• The crate name doesn't have to match the package name.
• There's no way to specify version constraints.
• There's no inherent way to correctly tell the difference between crates bundled with rustc and those you have to get via Cargo (and blacklists are dodgy).
• extern crate can appear anywhere in the source, so I'd need a full Rust parser, which brings up massive compatibility problems.

As such, I'm not going to do this. It's too much trouble to too small a gain.

[roblabla]

What about the other way around then ? Auto-generate an extern crate for each crate that's in the generated Cargo.toml ? This seems to fix all of the bullet-points.

[DanielKeep]

I could've sworn I've had that discussion before, but damned if I can find it.

You still have the exact same problem: the name of the package doesn't have anything to do with the name of the actual library. Knowing the package name doesn't tell you what the extern crate line has to contain.

Now, there's the -D / --dep-extern flag for expressions which does this, but that's only because there's also the -d / --dep flag which doesn't add an extern crate. Basically, you can only do this if the user tells you which one to use. At that point, you're having to add extra information to the script to tell it how to link to an external dependency... you might as well just write the extern crate out.

There's also another, softer reason why I don't like this idea: it means that you end up with .rs files that aren't actually compilable by anything other than cargo-script. I really like that the current system works in such a way that the extra manifest information is just a comment that someone can interpret themselves without having to modify the script, and just pass it as-is to Cargo or rustc if they want.

[roblabla]

Just a nit : Knowing the package name does tell you the extern crate line though. A package name is basically [a-zA-Z0-9_-]+ and the only 'weird' rule is that - becomes _.

I get what you mean about keeping some semblance of compatibility with the rest of the world, it's why the first idea was to take extern crate. I think I'm going to toy around with https://dtolnay.github.io/syn/syn/ and prototype something that does what I want, since it's something I'd really like for various reasons.

[DanielKeep]

Knowing the package name does tell you the extern crate line though.

No, it doesn't. You can name the library anything you want. Look at the winapi family of crates. The package kernel32-sys has a crate name of kernel32. There is absolutely no requirement whatsoever for the package name and crate name to share anything in common.

And, again, parsing the extern crate items has the exact same problem, just in reverse. Well, that and you also can't specify version numbers.

[bluss]

Just to have a more extreme example: Package piston2d-graphics uses crate name graphics.

[DanielKeep]

I'm tempted to make a small library crate whose package name is "raymond-luxury-yacht", but whose crate name is "throatwobbler-mangrove" just to drive the point home. :P

[roblabla]

Of interest : https://github.com/rust-lang/rfcs/pull/2088

And I will reiterate that knowing the package name does tell you the extern crate line, though the process might not be simple. You have to download the crate, untar it to get the Cargo.toml, and parse it to list all the libraries and get the crate name if that's necessary.

If we link against the cargo crate (instead of calling it) we can use the API to do this in a smart way, avoiding having to redownload the crate, and reusing the cargo logic to avoid platform discrepency. That's probably what I'm going to do.

[DanielKeep]

I originally intended cargo-script to link to Cargo itself for more information, but gave up based on two points: firstl, Cargo itself is a rat's nest of a codebase and I gave up trying to find a clean way of getting what I needed. Secondly, Cargo is/was a pain to build on Windows, and I didn't need it that badly.

Also, you might be surprised to learn I'm very much not in favour of that RFC. That said, if it gets accepted, then this becomes a completely moot point: the behaviour you want would just happen automatically without any changes needing to happen to cargo-script at all.