HOW to setup Windows 10 + VSCode + pymakr for Python programming + Micropython + ESP-IDF for esp32? - visual-studio-code

I started several attempts to get this complex working. As mentioned in so many other discussions the micropython modules are not recognized, e.g. machine. Python modules like numpy were also not found.
I think, the python environment is not working correctly and the modules are there but not found. But, there is no recommendation or tutorial that really solves this. How can I set this up?
What I did so far:
manually installed all components according to tutorials
another way: installed the pything coding pack which contains a lot of stuff.
The Windows paths have the correct folder paths to the components.
I set the obviously correct python interpreter in vscode
connection/communication with board is working. I can set up codes which dont contain micropython modules.
in other IDE's like thonny/mu the modules are found.
I also installed a python venv: I could install numpy inside this venv and later it was found in vscode (wasn't found before) when I used the venv python as interpreter in vscode. But I wasn't succesful with micropython in venv.
PS: I can use the micropython modules like machine or network and upload the sketch to the esp32 board. It is working on the board. But I cant run any of the sketches in vscode. I think that Vscode uses cpython instead of micropython but shouldn't this be working after the installations I mentioned?

It sounds like you're confusing modules you install on the machine running Visual Studio Code and modules you install in Micropython on the ESP32.
They're totally separate.
Python on your Windows machine can use venv.
MicroPython doesn't use venv at all (there apparently is a clone of venv for MicroPython but it's not readily apparent what it does or why or how you'd use it). It is a completely separate instance of Python from the one on your Windows machine, and it doesn't operate the same way. Modules you install under venv won't be visible or usable by MicroPython. Numpy in particular is not available for MicroPython.
Many modules need to be written specially to work with MicroPython. MicroPython isn't running in a powerful operating system like Windows, MacOS or Linux. It's running in a highly constrained environment that lacks much of the functionality of those operating systems, and that has extremely little memory and storage compared to them. You can't expect that a module written for regular Python will just work on MicroPython (and likewise, many MicroPython modules use hardware features like I2C or SPI access that may not be available on more powerful, general purpose computers).
Only modules available with upip will be available for MicroPython. They'll need to be installed in the instance of MicroPython running on the ESP32, not in the instance of Python running under Windows. They're two, totally separate instances of Python.

Related

Elpy to allow pyenv to work on a project basis

I've used Emacs for all my coding projects so far. Soon I will start some python projects for the first time and would love to stick to Emacs for these as well.
I was looking into elpy which seems to provide already alot of desired functionality. The part I was not able to figure out completely is the following. I like to define virtual environments and python version to be used on a project basis. Let's say I start a project A, then I would use pyenv-virtualenv or pyenv-virtualenvwrapper to set it up
pyenv virtualenv 3.4.2 my-virtual-env-3.4.2
by doing this I've linked the python version 3.4.2 to that specific virtualenv / project. I have two questions regarding this in combination with elpy.
Question: This is a rather basic one. All the above can be achieved via the terminal. What is the advantage to emacs to support this? The workflow for me would be: Create project with associated virtualenv and python version. Activate virtualenv and start coding in emacs. If I need to install a package I will run pip in the terminal to ensure virtualenv is captured properly. There must be a reason why it's beneficial to support this in emacs. With my lack of knowledge I just don't see it :)
As pointed out there is for sure a good reason why we want emacs / elpy to support this. My second question would then be
**Question: How can I achieve this in emacs? Lokks like this blog has a solution. I was wondeirng if someone already tried this setup if it is a neat solution with makes sense conceptually. **
Well I strongly guess the goal is to use more features than just syntax highlighting: flycheck/flake8/linting, refactoring, elpy's test runner to use the right python version, install a pip package directly from emacs, stuff like this. You can carry on doing this in the terminal, but once you want an emacs feature, you'll need to set it up.
IĀ found two modes to do that (see wikemacs python page and doubled-checked on melpa): pyenv-mode (in melpa) and pyenv-mode-auto (change the version when there is a .python-version file).

IPython notebook kernel dies on import

I am running IPython Notebook on Enthought's Canopy 64 bit distribution, Ubuntu 14.04.
I've tried install libtiff, but when I import it in IPython Notebook, the kernel always dies at the import statement. What could possibly be causing this? Canopy is my default Python distribution, my paths all seem like they're set up appropriately, although I'm convinced that something in my Python setup is borked.
Any advice is appreciated.
EDIT: I'll be more specific. Output of sys.path:
['',
'/home/joe/Enthought/Canopy_64bit/User/src/svn',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python27.zip',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/plat-linux2',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/lib-tk',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/lib-old',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/lib-dynload',
'/home/joe/Enthought/Canopy_64bit/User/lib/python2.7/site-packages',
'/home/joe/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/PIL',
'/home/joe/opencv-2.4.9',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/site-packages',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/site-packages/IPython/extensions']
As for how to install Python packages, I assume I go to ~/Enthought/Canopy_64bit/User/lib/python2.7/site-packages and run pip, setup.py, or a shell script, per the specific package's instructions. Is that correct? The article that I linked has the following line: "To install a package which is not available in the Canopy / EPD repository, follow standard Python installation procedures from the OS command line.", which seems to imply that I install per package instructions.
In .bashrc, I have the following:
VIRTUAL_ENV_DISABLE_PROMPT=1 source /home/joe/Enthought/Canopy_64bit/User/bin/activate
export PYTHONHOME=/home/joe/Enthought/Canopy_64bit/User/bin
export PATH=/home/joe/Enthought/Canopy_64bit/User/bin
export PYTHONPATH=/home/joe/Enthought/Canopy_64bit/User/bin
From what I understand of the linked articles, this means I'm setting Canopy User as my default Python distribution. I'm sure I'm doing something a bit over my head here, but I can't understand what else I need to do to fix this issue.
Worse yet, now I'm getting an "ImportError: No module named site" with these .bashrc settings, when trying to start IPython notebook or python from the command line. I can run only from the Canopy GUI.
Closing this. I made it harder than necessary.
It turns out, the PYTHONHOME and PYTHONPATH .bashrc variables were causing some conflicts. Commenting them out seems to have resolved the issue.
Installing outside packages does, indeed, happen from the home (~) directory.

Import error when using a python script that do not occur in ipython

All my install for python were working pretty well since soon. Now, I have a weird issue that generates import errors for some of my Python scripts and when using Ipython those import performs as expected.
This issue does not depend on the working dir (tested this several times with the same result). And I didn't change anything in my .bashrc regarding PYTHONPATHs.
So this might be a noob question, but is there an option in Ipython to display everything Ipython is doing when I run a command, so that I can track which is the package Ipython succesfully imported?
The packages I have trouble with are actually yaml, matplotlib cloud Image. Is it possible that an update from 2.6 to 2.7 is responsible for that? (I work on OSX Lion and most of the packages are installed via macports and updated using the upgrade outdated command).
As I think I can probably fix this myself with the command I asked for, don't bother seeking further for package compatibility or anything if you got the Ipython command that might suits me.
The difference of imports between python and ipython resulted from a cross defined python reference library (when installing most of the python libraries with macports and some without any known ports with other package managers).
Reinstalling the whole python libraries using the process described in http://astrofrog.github.io/macports-python/
corrects the issue and it is preferable to install manually the libraries that don't have any known ports (for instance with a setup build/install process).

MinGW or Cygwin GCC?

I want to install a GCC compiler in Windows for the Eclipse IDE. I know there are two options: MinGW GCC or Cygwin GCC. Which one is better for Eclipse CDT? Any experience or suggestions will be appreciated.
Using Cygwin means your program will be dependent on cygwin1.dll, which is essentially a layer that allows POSIX functionality to be used in a Windows environment. Compiling with the standard MinGW GCC provides no such dependancy. This means however, if you intend to compile with MinGW GCC, you will not have access to POSIX functions such as fork() and exec().
For more information on the differences between Cygwin and MinGW, see here.
My offhand thoughts are, if you need cygwin, you need it. For instance compiling programs that were developed for Unix and have symbolic links and shell scripts in the build system.
If you don't need it, you don't want it. And compiling under linux on a virtual machine is often a better choice than going the cygwin route.
So mingw is perfectly fine. Works fine, simple to use.
Also: You might consider codelite (www.codelite.org) instead of Eclipse.
Personally I like Cygwin better, it has a lot of installation options and it feels a lot like the terminal you'll find on a Linux machine. It provides a pretty substantial set of Linux-like capabilities, something that Windows fails at miserably.
Cygwin and Mingw are not interchangeable alternatives. Cygwin is used to compile POSIX API programs, Mingw is used compile Windows API programs.
Chose one or the other depending on what kind program you're going to write.
Wikipedia Says:
MinGW forked from version 1.3.3 of Cygwin. Although both Cygwin and MinGW can be used to port UNIX software to Windows, they have different approaches: Cygwin aims to provide a complete POSIX layer that provides emulations of several system calls and libraries that exist on Linux, UNIX, and the BSD variants. The POSIX layer runs on top of Windows, sacrificing performance where necessary for compatibility. Accordingly, this approach requires Windows programs written with Cygwin to run on top of a copylefted compatibility library that must be distributed with the program, along with the program's source code. MinGW aims to provide native functionality and performance via direct Windows API calls. Unlike Cygwin, MinGW does not require a compatibility layer DLL and thus programs do not need to be distributed with source code.
Because MinGW is dependent upon Windows API calls, it cannot provide a full POSIX API; it is unable to compile some UNIX applications that can be compiled with Cygwin. Specifically, this applies to applications that require POSIX functionality like fork(), mmap() or ioctl() and those that expect to be run in a POSIX environment. Applications written using a cross-platform library that has itself been ported to MinGW, such as SDL, wxWidgets, Qt, or GTK+, will usually compile as easily in MinGW as they would in Cygwin.
The combination of MinGW and MSYS provides a small, self-contained environment that can be loaded onto removable media without leaving entries in the registry or files on the computer. Cygwin Portable provides a similar feature. By providing more functionality, Cygwin becomes more complicated to install and maintain.
It is also possible to cross-compile Windows applications with MinGW-GCC under POSIX systems. This means that developers do not need a Windows installation with MSYS to compile software that will run on Windows without Cygwin.

Compile GTK+ with Cygwin

I have created an application in linux with GTK2 as GUI. It uses some linux-specific headers (e.g. arpa/inet.h) so to run under Windows I have to compile it with Cygwin. I downloaded the latest installer and choose to install GTK2 and its dependencies. My program compiled fine. But it needs X server to be running! I has old-style, ugly graphics and it doesn't open in a different window, like all Windows' applications do, but inside X server's window. Because of this it can't be portable. I found that guide, which is exactly what I need, but I get an error when I run "make" for GTK2 (undefined reference for _IID_IFilePersist, although I have uuid installed - also tried it with gtk2.20). Can you suggest what to do to build my application with cygwin? Or what do I need to install for the "_IID_IFilePersist" error? Thanks in advance!
There's prebuilt packages for windows that doesn't rely on X. http://gtk-win.sourceforge.net/home/index.php/Downloads
If you don't want X server to be running, then you're going to have to port the linux-specific parts of your code and compile with MinGW rather than Cygwin.