Skip to content
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

Use only installed Python on Windows #8226

Merged
merged 2 commits into from
Jul 26, 2021
Merged

Conversation

earlephilhower
Copy link
Collaborator

@earlephilhower earlephilhower commented Jul 18, 2021

When Python is installed on Windows separately (i.e. Windows Store,
Python.org MSI, etc.) it set the PYTHONHOME environment variable to
the installed path.

When we call our own portable Python, it tries to use the support
PYC files in PYTHONHOME. If they're from a different version of
Python, however, they won't work. Even though we're running our
own distributed Python.exe, we are crashing on the system-wide
Python installation.

Add -I to all python3 calls, ignore PYTHONHOME/etc. environment vars.

Tested under Ubuntu 18.04 Linux w/o any ill effects (we ship pyserial
ourselves and add it manually to the Python search path).

Fixes #8096, or should as I understand it.

@mcspr
Copy link
Collaborator

mcspr commented Jul 18, 2021

btw there's also -I aka isolated mode
https://docs.python.org/3/using/cmdline.html#id2

platform.txt Outdated
Comment on lines 161 to 163
tools.esptool.upload.pattern="{cmd}" "{runtime.platform.path}/tools/upload.py" --chip esp8266 --port "{serial.port}" --baud "{upload.speed}" "{upload.verbose}" {upload.erase_cmd} {upload.resetmethod} write_flash 0x0 "{build.path}/{build.project_name}.bin"
tools.esptool.upload.pattern="{cmd}" "{runtime.platform.path}/tools/upload.py" -E --chip esp8266 --port "{serial.port}" --baud "{upload.speed}" "{upload.verbose}" {upload.erase_cmd} {upload.resetmethod} write_flash 0x0 "{build.path}/{build.project_name}.bin"

tools.esptool.upload.network_pattern="{network_cmd}" "{runtime.platform.path}/tools/espota.py" -i "{serial.port}" -p "{network.port}" "--auth={network.password}" -f "{build.path}/{build.project_name}.bin"
tools.esptool.upload.network_pattern="{network_cmd}" "{runtime.platform.path}/tools/espota.py" -E -i "{serial.port}" -p "{network.port}" "--auth={network.password}" -f "{build.path}/{build.project_name}.bin"
Copy link
Collaborator

@mcspr mcspr Jul 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

{cmd} espota.py -E -> {cmd} -E -- espota.py?
assuming cmd expands to python.exe, arg is intended for python
(and also applies above, where python cmd is spelled out)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I will update soon. That’s what I get for submitting PRs at 2am…

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done with latest push. I was worried about -I and the scripts directory, but we don't have any cross-script dependencies so it does work fine.

For PlatformIO, it seems the builder script doesn't use the packages Python and relies on $PYTHONEXE which I assume is part of/required for Platform.IO.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, lgtm. (although, I'd still add -- for future's sake)

PIO itself needs system / bundled python to run, so it is slightly different there. e.g. with esptool, it just downloads a standalone script, since it already includes pyserial as it's core dependency

When Python is installed on Windows separately (i.e. Windows Store,
Python.org MSI, etc.) it set the PYTHONHOME environment variable to
the installed path.

When we call our own portable Python, it tries to use the support
PYC files in PYTHONHOME.  If they're from a different version of
Python, however, they won't work.  Even though we're running our
own distributed Python.exe, we are crashing on the system-wide
Python installation.

Add -I to all python3 calls, ignore PYTHONHOME/etc. environment vars.

Tested under Ubuntu 18.04 Linux w/o any ill effects (we ship pyserial
ourselves and add it manually to the Python search path).

Fixes esp8266#8096, or should as I understand it.
Copy link
Collaborator

@d-a-v d-a-v left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Build and flash is OK under ubuntu

@d-a-v d-a-v added the alpha included in alpha release label Jul 19, 2021
Copy link
Collaborator

@d-a-v d-a-v left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Compilation and flashing works under windows and arduino IDE.
tested using the alpha release.

@d-a-v d-a-v merged commit a0d2a7a into esp8266:master Jul 26, 2021
@earlephilhower earlephilhower deleted the pythonclean branch July 28, 2021 23:47
mcspr added a commit that referenced this pull request Jan 14, 2023
mcspr added a commit that referenced this pull request Jan 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
alpha included in alpha release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fatal Python Error when using any ESP8266 board with Arduino IDE.
3 participants