Paths are absolute

[yancyribbens]

I notice that rusty-tags calls ctags with an absolute path, and falls back to a path that's absolute in the case where the manifest returns a src_path that's relative. The problem is that I prefer to use docker to contain the environment for different languages/projects and install vim locally. Doing this breaks rusty-tags however because of path mismatches between local and container environments. I'd like to create a PR that allows for a absolute path option if a env var to the cargo registries location is present.

[dan-t]

Doing this breaks rusty-tags however because of path mismatches between local and container environments.

Can you please explain the break.

I'd like to create a PR that allows for a absolute path option if a env var to the cargo registries location is present.

I don't understand why this should be necessary, because 'rusty-tags' calls 'cargo metadata' which should handle this automatically.

I really don't want to add such an environment dependency, but just depend on the output of 'cargo metadata'.

I'm somehow open to add an option for relative paths, but first I need a clear understanding of the issue.

[dan-t]

The problem is that I prefer to use docker to contain the environment for different languages/projects and install vim locally. Doing this breaks rusty-tags however because of path mismatches between local and container environments.

Can you give me some infos about containers, because I never worked with them.

Is there some container equivalent to the root of a normal file system? How are file paths handled inside of a container?

[yancyribbens]

Hi @dan-t ,

I normally will run a container and mount the current working directory inside the container. For example: docker run -ti -v $(pwd):/tmp -v $(pwd)/registry:/usr/local/cargo/registry rust bash

This will mount ~/Git/rusty-tags (if that's the present working dir) inside a container at /tmp with Rust and Cargo installed. This also mounts a directory ~/Git/rusty-tags/registry which can be used to persist the crates installed.

If rusty-tags is run, it must be run inside the container since Cargo is required to retrieve the manifest. The path mismatch happens because if you execute rusty-tags vi from within the container in the example above, you get a tag file that looks like this:

Config /tmp/src/config.rs /^impl Config {$/;" c

however, since vim is on my local machine, if I try to follow this tag the location doesn't exist. Ideally there would be a way to make this tag file relative:

Config ./src/config.rs /^impl Config {$/;" c

That way, on my local machine vim would open the file at ~/Git/rusty-tags/src/config.rs. While I don't expect many people run a dev setup this way, it would be nice to have relative tags. A band-aid is just to run a regex over rusty-tags.vi from vim:

%s/\/usr\/local\/cargo\/registry/.\/registry/g %s/\/tmp/./g

However, this is cumbersome to keep updated especially if the project has multiple work spaces.

[dan-t]

Ok, thanks for the explanation.

Well, then rusty-tags does inside of the container context the right thing, but then a vim run outside of the container context can‘t handle the data from the container context, which seems somehow expectable.

Unfortunately, relative paths for tags can‘t work in the current design of rusty-tags, because tags files of dependencies are shared between different cargo projects. The rusty-tags.vi for the cargo project isn‘t the only tags file, but every dependency has it own tags file at its source root.

This design has several advantages:

• allows the jumping to the dependencies of a dependency
• reduces the rebuilding of tags for crates, they‘re build once and cached
• keeps the collision of tags as low as possible

Your current simplest workaround might be to define a symbolic link for the container root inside of your host file system, so that vim can find these paths.

[yancyribbens]

Thanks. creating a sym link on the host works as a workaround.

[dan-t]

I'm closing this ticket, because the current design can't support relative paths.