Support crates that aren't at the root directory

[randomPoison]

I run into the error described in #69 ("Could not find Cargo.toml") when my crate isn't at the root of my project directory in Atom. I still only have a single crate in my workspace, but I'm guessing that either atom-ide-rust or RLS isn't smart enough to determine where the root of the crate is if it's not the same as the root of the workspace.

Is this something that could be supported? Specifically, could we automatically determine the the root of the crate (based on where Cargo.toml is) if it's not at the root of the workspace? Or is there some reason why RLS will only work when the root of the project is at the root of the workspace?

This relates to #69, but I figured it would make sense to open a separate ticket for this specific feature request. If it would be better to include this directly as part of that issue, then I can close this down and copy the information over 🙂

[alexheretic]

A limitation we have from atom-languageclient is only a single language server will be spawned per project. Because of this the general solution for nested projects is using a cargo workspace, see readme#multi-crate-projects.

However, what if we handled in the case no root Cargo.toml exists by trying to find exactly one depth-1 child directory that had a Cargo.toml, would this help you out?

[randomPoison]

I found the note on multi-crate projects and was able to get my project working by adding a Cargo.toml to the root and effectively turning my project into a cargo workspace, which is an acceptable workaround for the time being.

Is there a reason why we could only support crates that are at the root or nested one level deep? i.e. we could support having the root Cargo.toml be arbitrarily deep so long as there's only one? If not, then at least supporting having the root be one level deep should be good enough for 80% of cases 👍

[alexheretic]

Checking at arbitrary depths is riddled with issues, what if you have Cargo.toml files at different depths, what if they're part of a workspace. Searching the entire tree could end up being fairly expensive. Yet this is an edge case anyway...

I tend to think either using a root cargo workspace, or simply opening your rust projects as separate atom projects is probably the way forward. The exactly 1 depth-1 child rust project scenario could work, but as soon as you add another project folder it'll break. I'm not totally sure it's worth adding extra code for this.

[randomPoison]

Yeah, that's a fair point. I imagine my use-case is pretty nice, so I don't care to push for a complex feature that will rarely be used. Thanks for the information, though!

To help with any other users that might have a similar nice case, though, would it be useful to add a note to the README that a cargo workspace can be used to make a nested crate work?

[alexheretic]

I think it would yes. readme#multi-crate-projects covers the idea, perhaps we could add that this is also a solution for nested rust projects within an atom project?