New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Have Mu use its own virtual environment #1061
Comments
Running through a virtualenv on Windows works fine on a development box. When an installed is built and installed, the packaged Python can't find the built-in venv module and so can't create the venv. |
Assuming that the approach of |
Sigh .. and now we can't import venv. (After adding enough logging to get us an error during the initial imports). I'll have to start digging into pynsist to understand how it gathers its modules |
Hmmm... and I can see that there's much happening in the Mu.launch.pyw part of the installer which results in a log file in -- uniquely -- %APPDATA% (ie not %LOCALAPPDATA%) so I missed it. |
... which comes from https://github.com/takluyver/pynsist/blob/master/nsist/__init__.py#L222-L257 |
Looks like venv isn't part of the Python embeddable zip. We'll have to pick it up elsewhere |
So I added virtualenv as an explicit install dependency then attempted to use its cli_run entry point to create the venv. That now fails on on the installed version with "ModuleNotFoundError: No module named importlib_metadata". I've got an idea that importlib_metadata is new in 3.8 (or 3.7) and we're shipping with an embedded 3.6 |
(from
So we'll have to include importlib_metadata as a dependency and/or consider upgrading to an embeddable 3.8. The problem there is that black has only published a wheel for 3.6 with a source dist for everything else. |
By the way I apologise somewhat for spamming everyone watching this, but I'm trying to keep track of what's happening and I assume you're all capable of muteing this particular issue. Thank you for your patience... :) |
We've now got to the point where it's trying to create the venv, But the virtualenv code is complaining about not finding the DLLs directory |
This is epic work Tim. Thank you so much for your efforts. 🥇 |
Just a bit of a pick-up as I've been fighting the infamous I've just come to a particular realisation, though, and I'm noting it here so I don't lose track of it later: we're launching Mu via the Mu.launch.pyw script which is generated by pynsist. When we
which is what the pywin32 tools need in order to invoke their |
Well that "works" in that it gets us over the
and restarting infinitely. And the REPL isn't working in dev / venv mode. Time for Round 2... |
To avoid confusion I'm closing this in favour of #1070 |
This is a retroactive issue for the work being done on the use-venv branch
The text was updated successfully, but these errors were encountered: