Log the user's environment when the attempt to execute pipenv returns ENOENT

[tristan957]

Environment data

• VS Code version: 1.21.1
• Extension version (available under the Extensions sidebar): 2018.3.1
• OS and version: Solus 3.999 (Linux)
• Python version (& distribution if applicable, e.g. Anaconda): 3.6.4
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): pipenv

Actual behavior

Getting a warning saying pipenv is not on path.

Workspace contains pipfile but attempt to run 'pipenv --venv' failed with Error: spawn pipenv ENOENT. Make sure pipenv is on the PATH.

which pipenv

$HOME/.local/bin/pipenv

pipenv installed using pip3 install pipenv --user

Expected behavior

Don't show a warning because it it clearly on my PATH

Steps to reproduce:

1. pip3 install pipenv --user
2. export PATH=$PATH:$HOME/.local/bin

Logs

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

No output shown

Output from Console under the Developer Tools panel (toggle Developer Tools on under Help)

No output shown

[MikhailArkhipov]

So if you run pipenv --venv from the workspace folder it does succeed?

[tristan957]

Yes the command succeeds

[DonJayamanne]

export PATH=$PATH:$HOME/.local/bin

I'm assuming pipenv --venv works only after you have setup the above environment variable.
Can you not add the above environment variable in your ~/.bash_profile file or similar?

[tristan957]

My bash profile is sourcing my bashrc where I am exporting the above path variable

[DonJayamanne]

Please try re-starting VS Code, ensure you have quit VS Code completely for the VS Code process to load the new environment variable.
Once done, please test once again.

[tristan957]

I have restarted my computer within the last 3 days many times. I experienced this same issue a few hours ago.

[DonJayamanne]

Ok, I believe know whats going on.
I believe this is similar to #1027 & #1254
Please could you add the necessary environment variables as defined here: http://click.pocoo.org/5/python3/

You can see how it was solved in #1027 as well.
Let me know how that goes.

[tristan957]

This did not work. Exported variables in bashrc. Logged out. Logged back in. Launched VSCode. I think an important discrepancy between my issue and the #1027 is that pipenv --venv works if pipenv is located in /usr/bin/ from what I remember. Attached screenshot to prove variables were set upon launch.

[tristan957]

I used to have pipenv installed at the system level, but I changed that because I found the --user flag for pip3

[brettcannon]

Is VS Code executing commands using a login shell? That would explain this issue as that could lead to one's .bashrc not being run (or even running bash depending on what the login shell is set to).

Maybe we need to provide a setting for specifying where pipenv lives?

[tristan957]

But VSCode still reads my bashrc properly. All my settings still exist in the integrated terminal. I really don't think the log in shell is the problem. I have Rust executables living on my appended path which the rust extension picks up just fine

[brettcannon]

@tristan957 all of that can be red herrings as the integrated terminal is not what the command passes through (e.g. look at Python's own subprocess module and how you have to specify the shell argument to forcibly go through a user's shell instead of a direct system call to execute the command). But since the solution for #1027 was picked up in a user's shell environment I'm assuming VS Code's API are passing through the shell.

Anyway, I know this is really basic, but just to double-check, what does which pipenv return in your shell? (Basically I'm grasping at straws here to figure out the issue.)

[tristan957]

output of which:

/home/tristan957/.local/bin/pipenv

I understand this is a complex bug. Weird that I am the only one commenting on this that has this issue. Let me know what else you may need from me.

[xhanrot]

Having exactly the same issue here. VSCode Windows 1.22.2 x64, Shell 1.7.12
Message : "Workspace contains pipfile but attempt to run 'pipenv --venv' failed with Error: spawn pipenv ENOENT. Make sure pipenv is on the PATH."

[brettcannon]

@xhanrot Please check that LC_ALL is set in your environment.

[tristan957]

Just to reiterate, setting LC_ALL did nothing for me

[brettcannon]

@tristan957 thanks. We just haven't been able to replicate your situation on our end plus being swamped preparing for our next release, so there hasn't been any movement towards fixing this yet.

[tristan957]

That's fine. I understand this is low priority. Thanks for the extension. I can clone the repo and make some changes to the extension locally to run tests if that would help you guys out too.

[brettcannon]

@tristan957 that would be amazing! Anything you can do to help track down what's causing this would be much appreciated.

[tristan957]

I would like to put a console.log($PATH), and then list the files in my $PATH. Where would I be able to put that in the code?

[brettcannon]

I'm thinking maybe we should send the entire env object to the console and print out to the Output window just, PATH, LC_ALL, and LANG since we know that's what's typically needed? That way the message can say, "Check the Output window for environment details" without overwhelming the user with information.

[brettcannon]

The other option is #1119 and tell people to run the command in hopes they will look themselves for the details we will point out to them.

[bendews]

I definitely think printing some useful information is a good step forward. $LANG and $LC_ALL tend to cause a lot of these sorts of problems for me so if the error message dialog makes those obvious that gets my vote. $PATH can be very cluttered and may drown out the other info (can it be delegated to the expanded view or just the output window?).

[ghisvail]

Still getting this issue despite the update.

[ghost]

I also got this issue in fedora 28 while installed via flatpak. However, after switching to official installation via rpm, the problem was solved.

[ghisvail]

Same here with Debian. Le 17 mai 2018 08:56, "moonrebels" <notifications@github.com> a écrit : I also got this issue in fedora 28 while installed via flatpak. However, after switching to official installation via rpm, the problem was solved. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1338 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB36bxld4qTmrneR-F3Qc-pHYCnl_pZrks5tzS0ogaJpZM4TLPoN> .

[dlukes]

@brettcannon

that means the pipenv command that VS Code is picking up when we execute is invalid and can't be launched via a system call

I don't think so, at least not in my case -- I have the same issue and the same error message, and the problem is that pipenv simply isn't found at all because my PATH customizations in ~/.bash_profile don't get picked up. If I hardcode the path to pipenv, then everything works fine (as in, the call to pipenv is executed):

dlukes@5f2aa09

If I inspect this.process.env[pathVariable] in the piece of code linked above, it only contains the default system-wide entries, not my user-specific customizations.

[tristan957]

That's what I was thinking too. Thanks for working on that @dlukes

[dlukes]

No problem :) One more thing: if I push my PATH customizations to the system-wide startup files, they do get picked up and pipenv is found.

On a related subject: I switched to bash (as in, chsh) in order to explore this issue, but I normally use zsh. Is the extension supposed to work even if all my environment configuration is in zsh startup files, or am I expected it to duplicate it in bash startup files? If it's the latter, I'm fine with that, but I think it would be a good idea to explicitly mention that in the docs / README / setup instructions :)

[dlukes]

OK, so my best account of what's happening is this:

• VSCode is launched via the code bash script
• the shell which runs that script is non-interactive (obviously, it's a script) and non-login, so on its own, it doesn't source ~/.bashrc nor ~/.bash_profile nor ~/.profile
• in other words, the only way for that shell to know about customizations performed in these startup files is to inherit them from the parent environment, which works fine if you run the code script from an interactive shell
• however, on my system (Solus OS), when I start VSCode via a .desktop file (e.g. from an application launcher), the code script runs in an environment in which the user's shell startup files haven't been sourced, so the customizations just aren't there for the code script to inherit

I think the easiest solution here is just to source "$HOME/.bashrc" at the start of the code script, so that you get the same environment as the one you use in interactive shells (it's not just about the PATH, there are other relevant variables like WORKON_HOME for virtualenvs etc.).

Incidentally, tweaking the code script is also a convenient way of ensuring that VSCode works with your setup if you're using a different shell than bash (zsh in my case, as mentioned in my previous comment -- I just changed the shebang to #!/bin/zsh and everything seems to work).

[dlukes]

One last thing: I was also getting a UnicodeDecodeError: 'ascii' codec can't decode byte... on a different box running macOS (from click, when VSCode was trying to run pipenv). This pointed to a misconfigured locale, i.e. another type of environment problem. I ran chsh, which informed me that my login shell was bash, and the crux of the biscuit was that I hadn't bothered to properly configure the locale in bash because I use zsh on that system. Troubleshooting:

• running code from a zsh command line, the error goes away
• more generally, changing my login shell to zsh (using chsh) makes the problem go away, irrespective of how VSCode is started

In any case, getting rid of this type of error is about running VSCode in the proper environment, i.e. the one you use in your interactive terminal sessions. These last two posts of mine are just a laundry list of things you might want to check and tweak in order to make that happen :)

[brettcannon]

@dlukes thanks for all the exploration! We obviously don't control the code command, so feel free to report that upstream to VS Code if you would like to see this changed.

And as for the locale issues, we plan to at least log if not warn users when we discover their locale isn't set such that click will have an issue.

[tristan957]

@dlukes can you link the issue here when you open it in the vscode repo, or subscribe me to the issue?

[dlukes]

I don't think this can be made to work automatically for everyone everywhere, as there's just too much variety in the kinds of setups people use, especially on Unix-like systems. But I do think users could be made more aware of this type of issues, and they could be given more convenient tools to address them, so I submitted a report to that effect upstream microsoft/vscode#50465 :) You're more than welcome to chime in!

[DonJayamanne]

Modified to log the following env variables:

• PATH
• LC_ALL
• LANG