Closed brianivie closed 3 years ago
So it looks like AWS is using the Python installed by your ESP-IDF installer script instead of using the one from Miniconda.
If you run which python
and which python3
, you should see it point to /opt/miniconda3/bin/python3 and /opt/miniconda3/bin/python3, respectively. However I get the sense that that won't be the case. Sometimes what helps is to deactivate your conda environments (including the base) with conda deactivate
TWICE. Then reactivating the edukit environment.
A fresh VM would reduce all of your variability. I would recommend a Linux VM over Windows any day. Windows only introduces more problems and is painfully slow at compiling with GCC.
Thank you for your time in looking into this and trying to help me.
Here is what I am seeing on an older Mac (10.13.6 High Sierra) after re-doing the conda create and activate: (In order to get AWS working I had to re-install it AFTER activating "edukit")
Then I get to this step:
After source-ing the export.sh file, python and python3 are indeed pointing the to the Python installed by the ESP-IDF installer script instead of the Minicoda one:
and the "aws" command no longer works:
How can I run step 4 of "Miniconda setup and installation" without it changing the path for python?
@brianivie, sorry for the delay responding to you. I'm able to replicate your woes. This works:
1) Source the ESP-IDF export shell script . ~/esp/esp-idf/export.sh
2) Run conda deactivate
twice to deactivate all conda environments, including the (base).
3) Run conda activate edukit
for miniconda to source it's files and insert the correct python location to path
4) Check with which python
Hope this fixes it for you. We'll introduce a better experience shortly that will fix this for all.
Thanks for the steps, and again for your help and insight.
I tried to follow your steps:
Source the ESP-IDF export shell script . ~/esp/esp-idf/export.sh You'll note minicoda has added itself to my .bash_profile file and so when I open a shell, it is in the (base) setting. Sourcing the ES)-IDF export shell script seemed to work just fine.
Run conda deactivate twice to deactivate all conda environments, including the (base).
Run conda activate edukit for miniconda to source it's files and insert the correct python location to path As I was in (base) for microconda the first deactivate turned off this environment, and then the second didn't seem to do anything. Activating edukit seemed to apply correctly, and I checked which version of python, and it was the one I had installed with edukit: 3.7.9.
Device Provisioning I then switched to the AWS_IoT_registration_helper folder and used pip3 to install the dependencies (still in 'edukit' version of conda) For each of the required libraries, the pip3 installer responded with "Requirement already satisfied:..."
I then tried to run the registration helper with the correct port: It was not able to find 'esptool'. (I think it lost it's ability to do this when I deactivated 'base' of conda which is where I had imported the settings for ESP-IDF.)
I am sad to say I was not able to get it to work following your instructions. I am happy to try anything else you might suggest, and I'm looking forward to the "better experience" that will be introduced shortly.
What happens if after you've done all that, you source the export script again with . ~/esp/esp-idf/export.sh
?
Are you getting the same errors about esptool?
I've been struggling to get the correct Python settings in order to run the registration help python script. This shows what I'm currently experiencing:
Should I switch to a container with Linux, or a VM with Windows? Know what version I should be installing/running in order to get the 'aws' CLI working as well as the other scripts? Could the instructions be modified to show the steps without the automation for people who are not able to get the automated scripts working?