error: the path link '/home/sanxiyn/download/zig' is not in PATH

[sanxiyn]

To reproduce, download zigup to $HOME/download/zigup, and symbolic link it to $HOME/bin/zigup, whereas $HOME/download is not in PATH and $HOME/bin is.

When zigup is executed, /proc/self/exe points to $HOME/download/zigup and not $HOME/bin/zigup, even if $HOME/bin/zigup was what was found in PATH, because kernel already resolved symbolic link.

[marler8997]

What's the behavior you'd expect or like in this case?

[sanxiyn]

The behavior I want is to behave as if --path-link $HOME/bin/zig is passed, not (as it currently does) as if --path-link $HOME/download/zig is passed, since the later fails anyway.

This probably can be implemented by searching PATH for zigup like which, instead of reading /proc/self/exe.

[marler8997]

There are actually use cases for not wanting the resulting zig path link in PATH. For example the zigup tests themselves don't want to actually put the resutling zig symlink in PATH. zigup's design has changed a bit so not putting zig in PATH may not be fully supported with every command (fetch seems to work but setting the default compiler doesn't). The fact that setting the default compiler in this case fails is a problem, but I'm not sure if we want to require that zigup be stored in a PATH directory. Since I'm not sure, I'm inclined to fix the error we currently get when setting the default compiler and just not require that it be a PATH directory. Which zigup command or commands did you run that presented the error?

[sanxiyn]

I ran zigup 0.9.1.

[marler8997]

You know what, looking at the code a bit more, it looks like zigup actually does make an effort to ensure that when you set the default compiler it is actually in PATH and is also the highest priority. The tests actually modify PATH. So ignore my last comment.

Your idea to detect when zigup does not live in a valid directory PATH but has been symlinked from a valid directory is an interesting one. My hesitation is do we need to add this complexity to zigup? The current solution in this case would be to copy zigup to the bin directory. Adding support for zigup to be symlinked from another directory adds some complexity/overhead. here is the current algorithm to the determine the path link directory:

https://github.com/marler8997/zigup/blob/9f8c5f98cd2052370ad676ebf287eb25106f2be8/zigup.zig#L120-L127

With your suggestion, this function would need to always traverse every directory in PATH to find any instance of zigup. Note that we would want to do this every time so that the path-link directory doesn't change depending on whether we are setting the default compiler or not. This also means that multiple instances of zigup in PATH would interfere with each other. Granted these are corner cases that would be rare, but my point is that having to handle these situations is the cost of adding such a feature. Without this feature, the status quo is that zigup must be installed in the directory where the user would like the path-link to be. If the user doesn't do this, then zigup is installed incorrectly and you get an error message. Another option would be to improve the error message:

error: the path link '/foo/bar/zig' is not in PATH, please move zigup into a directory that is in PATH

Is there an environment or a reason why you wouldn't be able to move zigup to a directory in PATH?

[sanxiyn]

I think improving the error message would be fine. I actually solved this for myself just as you suggested, by copying (instead of symlinking) zigup to bin directory. But it was mystifying at first why it failed, and it was unclear the solution is to copy.

There is no particular reason I symlink, it's just that I always did it that way for like a decade and it worked fine. In download directory, I keep metadata (like where and when I downloaded it), and those don't belong in bin directory, and copying seemed wasteful of space, so I symlinked.