So I'm testing out the SPy library in Anaconda's Spyder, and have run into a strange error:
SystemExit: This program needs access to the screen.
Please run with a Framework build of python, and only when you are
logged in on the main display of your Mac.
This happens when I try to call the view_cube command from Spectral Python (SPy), which requires wxPython.
I have a feeling that this is related to Spyder's displaying of all the images generated by my program in its onboard console, instead of in independent windows.
How can I fix this error, and is there a way to tell Spyder to display images in their own windows? Can I run a "Framework Build" within Spyder?
EDIT:
I was able to display the resulting images in separate windows by going to Preferences > IPython console > Graphics, and setting Backend to Mac OSX. However, the error when trying to run the view_cube command still persists...
I expect you're using the system version of python that comes installed on mac by default, which isn't a framework build.
You'll want to install a version of python from python.org which are all framework builds. I expect you'll want the latest version of python 2. You will also have to install your dependancies again against this new python install.
Related
I am writing a project in Python 3.9 using Visual Studio Version 17. This project uses colorama to add color to the terminal text.
Recently, I installed anaconda on my computer as part of an unrelated project. When I returned to my original project in VS and tried to run it, I found that the output window no longer renders the colors; instead it outputs the raw color codes from colorama such as ←[33m. However, when I run my project from the terminal directly, everything renders correctly.
I should note that there are 3 environments currently available for my project: Python 3.9 (which I was using before), Python 3.10, and Anaconda. Only Python 3.9 runs because the other environments do not have other dependencies installed such as scapy. Not sure if it's relevant to my issue, but figured I would mention it.
Found the issue. Forgot to add colorama.init() to the start of my code.
I am trying to install a model management framework over python.
I have python 3.6 and windows 8.1. I was able to successfully install the plugin.
However, when I try to start the visualizer using the studio ui command, I get 'studio' is not recognized as an internal or external command
Most of the resources I have checked online show the installation on linux where this works, how do I get this to work on windows?
Site
Documentation
GitHub
I feel like I am missing something very basic here.
Kind of figured it out.
Apparently setuptools has the provision for specifying entry points. Sample file:
[console_scripts]
mlflow=mlflow.cli:cli
When pip (or another console_scripts aware installer) installs the distribution, it will create a command-line wrapper for each entry point.
So that if we type mlflow on the command line, it is automatically recognized.
So now I am able to run it by running the actual cli.py file with arguments, still need to figure out why this failed on my PC though.
Links: Here, Here and Here
I am running Debian 8.7 (Jessie) on a development laptop. I am just getting into Python development for some machine learning projects I am working on. I also have Python installed on a my main Mac OSX macbook as well.
While working on some examples, the OSX install, when using plt.show() (from Matplotlib/pyplot), a window will pop up with the plot. On the Debian laptop, however, I get nothing back. No errors, nothing. I changed the plt.show() command to just save the figure out to a file and that works.
I read some forums and posts that talk about installing ImageMagick and other tools. I have tried that, but that didn't seem to work. Another option was to change the "backends". I also read something about using "eog" instead of the xv or display provided by the base OS. The post is located here:
matplotlib does not show my drawings although I call pyplot.show()
I went through this process, but that doesn't seem to work either. I'm wondering if this has something to with the fact that I had to download, configure and make the Python 3.6.1 version I am running on the Linux side. I'm still a little new at Python, so I'm unsure how to solve this.
Info:
OS: Debian 8.7 (Debian)
Python Version: 3.6.1
Packages Installed: pandas, matplotlib, bokeh, scikit-learn (and all the other major data science and machine learning libraries/packages). I used pip3.6 to install these, since the default python install is 2.7.9 on the OS.
Please let me know if there is more information needed. Thanks!
Have you tried checking whether you're using python 3.6 instead of the 2.7? Try checking your bashrc.
I had a similar problem before with seaborn because i was using 2.7 at first and changed to 3.6. I used spyder now so my default python and projects will not get confused. Or you could try Python Virtual Environment.
I am trying to learn something about GUI and game programming, so I was wanting to install Pygame. I was reading through how to install it, and I was recommended to make sure I had the latest version of either Python 3.3.x or 2.7.x installed in order to be most compatible. I had an earlier version of 2.7.x installed, so I attempted to update my installation. I downloaded and installed (went through the whole installation process) for the new version of 2.7.x, though I didn't uninstall anything (I don't even know how to uninstall Python as it doesn't show up in programs and features). Now, when I try to open IPython, I get redirected to the Windows Command Line rather than the interactive Python window. I need the interactive Python for work and school, so how do I regain functionality to that.
I looked in the folder containing all my Python installation data, and I found that there is no Ipython.exe file, but rather that the source of my IPython installation seems to be a .bat file instead. Is this correct? For being a computer science major I'm really bad at all this stuff.
Thanks!
I have EPD 7.3 and have installed wxPython 2.9 through the Enthought repositories. I tried running winPDB, which requires wxPython and I got this message :
This program needs access to the screen.
Please run with a Framework build of python, and only when you are
logged in on the main display of your Mac.
I have seen similar messages from wxPython on Mac, but I haven't found a solution yet. Does anyone know about this message? And, has anyone got WinPDB to work on OS X 10.8 w/ wxPython 2.9?
This error message will happen when the Python used to run a wxPython script is not a full framework build. OSX requires that applications that are given full access the screen be run from an application bundle or are part of a framework.
Usually all Pythons are framework builds these days and there is no need to worry about this any more, however there is one situation where it is still an issue, and that is with virtualenv or similar tools. With the way that the virtualenv is constructed the Python that is there sort of loses its connection with the framework that it comes from, and so using it directly triggers that security mechanism and the wx code is not able to get full access to the screen. If you are experiencing a problem in a virtualenv then I've written up a workaround here: http://wiki.wxpython.org/wxPythonVirtualenvOnMac
Hmm... I just went to double-check this with EPD and I found that the "python" executable they provide is not a front-end for the Python.app binary like in normal framework builds, but is more like a normal unixy Python. Since I'm at Enthought now I'll ask the responsible parties if this is a bug or is intended, but in the meantime you can work around this by changing which Python is being executed. For example, you could create a "pythonw" alias in your bash shell that points to the Python.app binary, like this:
alias pythonw=/Library/Frameworks/EPD64.framework/Versions/7.3/Resources/Python.app/Contents/MacOS/Python
Then you should be able to run WinPDB or other wxPython applications by using pythonw instead of python.