Closed Bug 1384731 Opened 7 years ago Closed 7 years ago

rustc cannot be found in the path if given path uses ~ for the user's home directory

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(firefox56 fixed)

RESOLVED FIXED
mozilla56
Tracking Status
firefox56 --- fixed

People

(Reporter: bytesized, Assigned: bytesized)

Details

Attachments

(1 file)

I added "~/.cargo/bin" to my PATH variable (and restarted my shell) and continued to get the error:

    ERROR: Rust compiler not found.
    To compile rust language sources, you must have 'rustc' in your path.

I ran |which rustc| which returned "/home/ksteuber/.cargo/bin/rustc", indicating that rustc in fact *is* in my path. I poked to try to determine how it was discovered that rustc was not in my path and found mozilla-central/third-party/python/which/which.py. I noticed that a call to "os.path.expanduser" was conspicuously absent.

Changing my PATH variable to instead contain "${HOME}/.cargo/bin" caused the error to go away.
This change seems to be within third-party code. The header indicates that the home page for this project is here [1], but that URL simply loads a "Not Found" page. Does this change need to be made upstream, or should we just incorporate the change into our own codebase?

If we do incorporate the change into just our own codebase, who do I get to review this?

[1] http://trentm.com/projects/which/
Assignee: nobody → ksteuber
Flags: needinfo?(gps)
~ is a shell primitive. ~ is typically expanded when PATH is evaluated by your shell. That's why it is arguably OK to not expand ~ in PATH.

Since you are the first person to complain about this issue AFAIK, I'm going to assert that ~ in PATH isn't a common thing and shouldn't be supported.

Is there a good reason to support ~ in PATH?
Flags: needinfo?(gps)
While the shell is happy to expand the ~ character, it does not expand the PATH variable on assignment and we are not determining the file's existence in the path with the shell. We are determining it with os.path.isfile [1], which does not expand the ~ character.

But as to "Is there a good reason to support ~ in PATH?": Isn't there? Does it really make sense for our build system to impose requirements on how my PATH is formed?

If you really do prefer to do it this way, please rephrase the error message "To compile rust language sources, you must have 'rustc' in your path". rustc is in my path. This error message is therefore incorrect.

[1] http://searchfox.org/mozilla-central/rev/8a61c71153a79cda2e1ae7d477564347c607cc5f/third_party/python/which/which.py#202
Flags: needinfo?(gps)
GNU which supports ~ expansion.

It is a legitimate feature request to want our build system to do ~ expansion in PATH.

The which Python package appears to be dead. I'm not opposed to landing patches to it in-tree. Flag me for review if you want to change it.

Long term, we probably want to move off the which package because it is dead. There are other changes we want to make (like bug 1382940) that may require enough changes for us to just reinvent the functionality somewhere in the mozbuild package land. But that's beyond the scope of this bug.
Flags: needinfo?(gps)
Attachment #8890564 - Flags: review?(gps)
Comment on attachment 8890564 [details]
Bug 1384731 - Allow which to find files in paths that use the ~ character to represent the home directory

https://reviewboard.mozilla.org/r/161708/#review167898
Attachment #8890564 - Flags: review?(gps) → review+
Pushed by ksteuber@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b6ef3ef539fc
Allow which to find files in paths that use the ~ character to represent the home directory r=gps
https://hg.mozilla.org/mozilla-central/rev/b6ef3ef539fc
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.