06-10-2019 09:32 AM
I'm having problems using Python within TCL in the same build scripts I have been using for ages. Since I installed Vivado 2019.1 it seems to call a built in Python 2.7.5 in Vivado (which is broken), not my installed versions. I've tried using the Python installation path directly to no avail - anyone having a similar problem or know a way around this?
06-10-2019 08:29 PM
Could you post more details about what error/phenomenon you encountered?
06-11-2019 10:02 AM
Sure... I've only tested this on Windows 10, and it appears that all Python scripts called from within the Vivado TCL environment are intercepted and instead use the following:
Obviously the install location may be different... it doesn't matter how I try to specify the Python install path, it always utilizes the Xilinx packaged interpreter.
The error occurs within the GUI and on the command line (cygwin or DOS); the GUI error occurs in my situation post synthesis when executing a tcl.post script that calls a Python sort logs script. The command line error is similar and occurs at any point within the Vivado TCL shell - the following screenshot is an extremely simple example to demonstrate the bug:
I have tried callling the install paths directly (even is desperation as a variable) to no avail.
06-11-2019 07:28 PM
Could you share your .tcl and .py scripts so that I can reproduce the issue at my end?
06-11-2019 09:25 PM
Would you modify content at line 123 in <install dir>/tps/<win64 or lnx64>/python-2.7.5/lib/python2.7/encodings/__init
__.py as below ?
raise CodecRegistryError, \
06-12-2019 11:47 AM
Watari - I actually tried that already, cheers. I also removed the line breaks in frustration, nothing.
Vivian - In my previous post I included cat commands before the script to show what they are doing. Sorry, perhaps I should have made that more clear... the command just displays the contents of the scripts to console.
Does anyone know if there is a way to simply bypass the built-in Python and use our own installation? Version 2.7.5 is really quite old anyway...
06-13-2019 01:25 AM
The following thread may be helpful:
Seems it is with environment variable settings or administrator priviledge.
06-13-2019 10:21 AM
Thanks for that - it looks compelling but I think this is a different problem. Running as administrator makes no difference (in either DOS or CYGWIN shells), and as the post eventually hints on, the PYTHONHOME and PYTHONPATH environment variable are not meant to be set... unless you need to point to additional user libraries, etc.
Besides Python not working at all, the more crucial problem for me is that the Vivado interpreter forces the use of a Python version that is incompatable with a number of our companies scripts. This means even if we can get this to work, we still have a ton of re-writing to do that affects many people in many projects in many locations and isn't something easy to deploy. What I really need is a way to stop Vivado forcing a particular version and allow the user to determine the best tool for their flow.
07-22-2019 10:29 PM - edited 07-22-2019 11:44 PM
Same problem occured to me, see if below solution helps; Need to run these commands in Vivado 2019.1 before executing user Python:
08-01-2019 03:26 PM - edited 08-01-2019 03:27 PM
Ok after the unset and resetting the pythonpath and pythonhome variables it works now. :)
set ::env(PYTHONHOME) "/usr"
set ::env(PYTHONPATH) "/usr/lib64/python2.7.zip:/usr/lib64/python2.7:/usr/lib64/python2.7/plat-linux2:/usr/lib64/python2.7/lib-tk:/usr/lib64/python2.7/lib-old:/usr/lib64/python2.7/lib-dynload:/usr/lib64/python2.7/site-packages:/usr/lib64/python2.7/site-packages/gtk-2.0"
To figure out how to set PYTHONPATH do the following on your command line:
>>> import sys
['', '/usr/lib64/python27.zip', '/usr/lib64/python2.7', '/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk', '/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload', '/usr/lib64/python2.7/site-packages', '/usr/lib64/python2.7/site-packages/gtk-2.0', '/usr/lib/python2.7/site-packages']
09-16-2020 09:18 PM
Actually since Python is already included on my $PATH (Windows 10) I just had to unset those two variables and it worked.
unset ::env(PYTHONPATH) unset ::env(PYTHONHOME)
Thanks for the tip!