Sample doesn't work under pipenv / virtualenv about fprime

[ljreder]

I use virtualenv as well and it is a known problem how to handle these. The work around however, is to set the PYTHON_BASE to your desired Python interpreter (e.g. your virtualenv one) and that will override the Makefile system set one. It becomes a little more work if your doing multiple environments.

Also you can try using virtualenvwrapper tool which allows controlling the environmental variables on a per virtual env occurance. See https://realpython.com/python-virtual-environments-a-primer/#managing-virtual-environments-with-virtualenvwrapper. I have not tried this but if it helps and works out let me know.

[yashi]

Do you have any idea about the problem we had when we just to run python, assuming that users has properly set up their environment?

[LeStarch]

Currently, PYTHON_BASE is embedded in our sample shell scripts. It should be fairly simple to fix this, and we have it in the works. However for the time being, setting PYTHON_BASE to your virtual environment should work. This is how I work, and it functions pretty well.

I have found a few corner cases where this does break, and fixes are underway for those too.

[brianthespoon]

Any easy fix I was able to implement was to edit the "activate" script in my virtual environment "bin" with the following:
export PYTHON_BASE=$VIRTUAL_ENV

I use python virtualenv, which sets this VIRTUAL_ENV variable. I simply leverage that by setting PYTHON_BASE to it. Currently it looks like the make scripts check for PYTHON_BASE, and use a default value of "/usr" if it's not found. Perhaps it can also check for virtualenvs signature "VIRTUAL_ENV" variable?

[LeStarch]

Yes, I use that fix for the time-being too. I am working on patch that will remove the dependency on PYTHON_BASE. I will comment here when it is being delivered.

[LeStarch]

This should be fixed in the latest devel.

[LeStarch]

Closing.