Allow external Cargo.toml
Closed this issue · 4 comments
This may seem like a weird request for the nature of this tool, but it would be very useful to be able to use this for scripts in existing cargo projects. (copying assets and such)
It would also be useful to have this when you have a bunch of scripts and you just want to have the dependencies together in one file.
But if you have a Cargo.toml file, then you have a Cargo package and you can just use cargo run --bin NAME. If, for some reason, the scripts in question don't share dependencies with the rest of the project, then you wouldn't want to use the same Cargo.toml as everything else.
I just don't understand how this would be useful and not already covered by Cargo.
Cargo bin is assumed to be binaries part of the project rather than scripts that are part of the build process. As well, building the cargo project might require some script to run first. Some types of projects need asset processing before the main project crate can even be built. This can be included in build.rs but for some things it's nice to be able to do this manually and have multiple separate scripts.
I'm not sure this, as stated, is all that useful for what you're describing.
I mean, you say "external Cargo.toml", but do you mean that? I mean, does that include the links setting? What about compilation profiles? Should it use dependencies or dev-dependencies or build-dependencies? All of the above?
Being able to centralise the list of dependencies could be a little handy, but violates the spirit of "self-contained Cargo packages". There are also some practical issues I can think of: this will probably require new syntax, (probably) new command-line arguments, changes to how the manifest is parsed, complicated merge logic (merging arbitrary TOML isn't trivial). I don't feel like the changes are justified by "slightly less typing".
I just don't feel that this is compelling in terms of cost/reward. I'm not saying you can't convince me otherwise, but that's my take at the moment.
Reading over what you've written and further thinking, I think the problem with this is that what I'm looking for is simply not what cargo-script does. What I'm looking for is a task runner similar to gulp, which is built to be part of the build process, but cargo-script is focused on self-standing scripts.