installing the Python dependencies to a directory called "~" in the nvda checkout.

Oh yes, I forgot you mentioned that.

So we somehow need to copy these across from the real environment.

I'll take a look at that.

I'm afraid it would fail in the following situation:

1. Developer has standard user account on which he does most of his work, so he installs dependencies at the user level for that account.
2. For a particular issue he has to work on an admin account so he writes code there and when he is ready he tries to lint his changes still under this account.
3. The process fails because Flake8 is not installed however installation isn't triggered, because the _executed_requirements.txt exist.
4. He tries to install flake8 with scons lintInstall and installation isn't performed.

Would it be possible instead of copying requirements file and using it to determine if dependencies are installed simply attempt importing flake8 and flake8_tabs and if import fails perform installation?

attempt importing flake8 and flake8_tabs and if import fails perform installation

Couple of downsides to this:

• We have to maintain a second list of things to test for importing, matching our requirements file.
• We also want to check for versions, currently the lintInstall step runs again when the requirements file changes.

I have had a quick look at importing environment vars to try to get this into the right place, short of importing the full external env, I think this will be error prone. I am now in a situation on my local system where flake8 is installed to some random folder in my user directory, not the standard --user location. I think i need to use SCons to uninstall 🙄

Importing the full env is not really ideal either, this can easily cause strange outcomes on different systems.

I think the best eventual option is to use virtual environments to handle python deps. Tox automatically sets up virtual envs and runs tests in the chosen environment.

We have to maintain a second list of things to test for importing, matching our requirements file.

It should be possible to parse requirements file in the sconscript, import what is included there and even check for versions. I have no idea if it would be easier than going with virtual environments.

We also want to check for versions, currently the lintInstall step runs again when the requirements file changes.

If the file would be properly parsed with a version check it would also be done.

Editing the same source copy with multiple user accounts seems like a recipe for permission problems. It's also somewhat contrary to how UAC is meant to work.

As long as source code isn't stored in the user directory I don't thing it should be problematic.

Why not just use an admin account and elevate only when needed?

This PR was created precisely because some developers are using standard accounts. It is apparently more secure.

@lukaszgo1 commented on 9 aug. 2019 14:36 CEST:

We have to maintain a second list of things to test for importing, matching our requirements file.

It should be possible to parse requirements file in the sconscript, import what is included there and even check for versions.

I think this sounds interesting. pip is able to parse these requirement files, so I assume it has some functionality to get the appropriate package names from them.

It looks like calling second python interpreter with subprocess.call installs these dependencies to the right place. It certainly isn't as pretty as a virtual environment, but is a lot simpler.

I don't think this is a good approach, I'm closing this PR.