You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On every operating system but Windows, we're able to make some assumptions about which python version we're referring to by being specific, such that we know python3.10 -V will return something along the lines of Python 3.10.x. On Windows, for whatever reason, this is not the case, as all python interpreters are named python.exe.
Currently, InvokeAI's automated installer requires a non-default option, 'Add python.exe to PATH', to be checked when installing the official package from python.org, or it'll fail. This is responsible for the vast majority of support issues that we see, and probably the popularity of the standalone version which was recently removed from itch.io. In addition, this option could inadvertently break the installation of other python-requiring software that also made this choice/requirement.
There's already a solution for this, and it's the py launcher that comes with every python installation from python.org. It accepts a version as the first argument to it, and is available in PATH without any non-default options checked. An example:
py -3.10 -V would be the same as python3.10 -V, and py -3.10 -m pip install xformers would be the same as python3.10 -m pip install xformers.
This should hopefully be pretty easy to implement in the installer and would save many, many people a lot of time.
Alternatives
Not so much an alternative, but a counterpoint: the py launcher isn't included with the python from the microsoft store, so this proposal wouldn't help there.
An alternative might be to just require that the end user chooses the right python to launch the installer, with some documentation explaining the various ways to provide that, depending upon how python was installed.
Aditional Content
No response
The text was updated successfully, but these errors were encountered:
Reviving this issue because I now have a Windows PC to test on once again. I've created a quick hack of install.bat (not install.bat.in) from the latest 5.0 installer.
Replacing python with py -3.11 in two places works fine as a proof of concept:
line 45:
call py -3.11 --version >.tmp1 2>.tmp2
line 68:
call py -3.11 .\lib\main.py
My guess is that somebody that's actually familiar with .bat files could make this more elegant and check for py 3.11 and, if not found, try py 3.10.
Is there an existing issue for this?
Contact Details
No response
What should this feature add?
On every operating system but Windows, we're able to make some assumptions about which python version we're referring to by being specific, such that we know
python3.10 -V
will return something along the lines ofPython 3.10.x
. On Windows, for whatever reason, this is not the case, as all python interpreters are namedpython.exe
.Currently, InvokeAI's automated installer requires a non-default option, 'Add python.exe to PATH', to be checked when installing the official package from python.org, or it'll fail. This is responsible for the vast majority of support issues that we see, and probably the popularity of the standalone version which was recently removed from itch.io. In addition, this option could inadvertently break the installation of other python-requiring software that also made this choice/requirement.
There's already a solution for this, and it's the
py
launcher that comes with every python installation from python.org. It accepts a version as the first argument to it, and is available in PATH without any non-default options checked. An example:py -3.10 -V
would be the same aspython3.10 -V
, andpy -3.10 -m pip install xformers
would be the same aspython3.10 -m pip install xformers
.This should hopefully be pretty easy to implement in the installer and would save many, many people a lot of time.
Alternatives
Not so much an alternative, but a counterpoint: the
py
launcher isn't included with the python from the microsoft store, so this proposal wouldn't help there.An alternative might be to just require that the end user chooses the right python to launch the installer, with some documentation explaining the various ways to provide that, depending upon how python was installed.
Aditional Content
No response
The text was updated successfully, but these errors were encountered: