My company releases part of its product as Python scripts running on an embedded Linux-based system. For our production release, I want to set the environment variable PYTHONOPTIMIZE="1" so that all Python scripts will be run as if the "-OO" switch were specified.
However, the scripts will be running by a user who isn't logged in (for example, some are invoked via the web server and others are started via systemd) so I can't simply set PYTHONOPTIMIZE in, e.g., /etc/profiles.
One solution might be to modify the shebang in each Python script to include the "-OO" switch but this seems a little involved. Is there an obvious way to make Python execute all Python scripts using a default environment that I missed?
Related
I am fairly new to creating Python applications. I have fooling around with some small tutorials and applications using PyCharm and have always created a new project using the Virtualenv environment, ending up with a "venv" folder under my project folder. I have not had any problems with this, but then again I have not done any large projects.
However, I have been wanting to learn Flask want to try to create a new Flask project the proper way. I see in many tutorials that people are creating (and activating) the virtual environment from the (Windows/Linux) Command Line instead even though they are using PyCharm and I was just wondering what the difference is?
When I work on a project in PyCharm, created with Virtualenv, I do not activate the venv before working on it. Is this wrong or is this something that is handled by PyCharm? What if the venv is created from a Command Line? Is it still handled (activated) by PyCharm if working on the project there. And what about the folder structure? Is this affected by how the virtual environment is created? Is there somewhere I can find some "best practices" for the setup / folder structure when creating Flask project within a Virtual Environment?
PyCharm activates the VirtualEnv for you if it is configured to use one and told where it is (more specifically, where the respective Python binary in the VirtualEnv is).
There's no real difference between manually created VirtualEnvs and ones created by PyCharm. (Apart from the framework you select to create one in case this is different from what PyCharm is configured with.)
If you want, you can just create one manually and then point PyCharm to it. Either during creation of the project or later using the Settings dialog (see Settings -> Project -> Project Interpreter). It will then treat it no differently and also activate it for you when working inside the IDE.
A virtual environment is pretty much just a folder which stores installed Python packages and isolates them from the rest of your system. This is so you can work on different projects which may all have competing requirements for external packages, without getting into conflicts. "Activating" a virtual environment just sets certain environment variables in your current shell so it'll use packages from this environment. "Activating" an environment never has any impact beyond your current shell. So activating an environment on the command line won't do anything to PyCharm.
PyCharm integrates a Python interpreter to give you lots of extra functionality. You tell PyCharm which interpreter you want to use for your project and it'll figure out what packages it has available, what version it is, and automatically set everything up properly for running your code from PyCharm etc. You can tell PyCharm to use your system's Python interpreter or an existing virtual environment or even use it to create a new environment. You don't need to do anything special beyond just selecting the right interpreter/environment in the project settings.
There's no reason to activate the environment from the command line if you're not going to use it from the command line. Of course, using Flask and running its server from the command line and keeping it running in the background may be useful. Not sure if PyCharm would give you an easy or integrated option to have persistent processes run in the background. You could still select the same virtual environment in PyCharm and use it to run your tests in it directly from PyCharm, use its debugger etc.
I prefer to keep the venv out of the project folder and store all venvs in ~/.virtualenvs/ or such. It declutters the project folder and prevents accidentally checking those files into the version control system.
I was just wondering what the difference is?
There's many tools for creating and using virtual environments and there's no difference between them, the only difference between them is their commands syntax (or the way it interact with users, e.g. for Pycharm you set some settings via GUI).
Is this wrong or is this something that is handled by PyCharm?
There's nothing wrong with it. As long as you have a venv (or .venv) directory in the root of your project and it is executable for any user, Pycharm will use it and it activates this virtual environment for you (without telling you). If Pycharm was not able to do that, (because of trouble in finding venv or activating/executing it!) then it will show you messages to fix its problems and it can't run your project till you fix them.
It's better to create your virtual environment in .venv directory right into the root directory of your project. (It's kind of conventional)
See python virtual environments and configuring pycharm virtualenv as well.
I just started using python and pycharm. I'm a bit confused of what is the run configuration in pycharm do and what is the different between the just run ?
A run configuration (not just in PyCharm, for example JetBrains IntelliJ also has them, in fact most IDEs have this concept) is a compilaton of settings to be used when running a program.
Let us stay with Python for the sake of simplicity. You might think that when you execute your script by typing in your command prompt...
python myscript.py
...that there are no settings or configuration involved. You are just running your script, right?
Not quite, you are in fact using what you could call an implicit run configuration, i.e. are whatever defaults and environment settings happen to take effect.
Some examples you will also find in PyCharm Python run configurations:
Script path is just the script you are calling, in the example myscript.py since we specified that on the command line.
Python interpreter is whatever Python interpreter is first in your path.
Parameters is empty in our example, as we didn't specify any on the command line.
Working directory is the current directory, where we are with our command prompt.
Enviromnent variables are those that happen to be set in our shell.
All of these and more can be defined in a run configuration (or multiple different run configurations if you need) for your project.
You can then select these conveniently from the dropdown menu, and the one currently selected will be used to execute your program when you press the green play button.
What is the difference between using a run configuration and just run in PyCharm?
If you just run your program, you are telling PyCharm that it should just use the project default configuration for the specific file type.
In other words, you are using a run configuration as well there, just the unmodified default configuration.
I have shared web hosting space with python 2.6.6 pre configured, now I have installed python 3, I have created the virtual env for the same & activated it.
My question is - How can I keep the python3 virtual environment activated all the time, even when am not using the console/putty.
The problem is I have imported couple of libraries to python3 & want to use it, but if my console/putty is closed my header line in .py files has to be pointed back to #!/usr/bin/python >>but this points to python2.6.6.
Whereas I want the python3 should always work. All the users coming to my website, their requests needed to be processed by python3 instead of python2.6.6.
Really searched a lot but could not get this specific information.
Thanks...
You're thinking of this in the wrong way. If they're coming to your website, then they're using your web app. It's only that that needs to run under the virtual environment, which you would configure in its own startup script (eg the wsgi script).
We have an in-house developed network-based application that is based on python, it provides a command-line environment in the same way like python does. I also have a local python installation on my machine. Sometimes for simple python tasks, i prefer using my local python install... Is possible to to have a different PYSTARTUP env variable for each of installation?
You can always export PYSTARTUP="whatever" on the shell before starting your script.
You can also put PYSTARTUP="whatever" in front of the command you want to run, e.g. PYSTARTUP="whatever" python something.py
I'm using Python 3 for developing and CollabNet Subversion Edge as versioning software. Subversion Edge comes with a little program called ViewVC which is written in Python 2, which is also directly bundled with it. There is a system environment variable called PYTHONHOME.
If it is set to the Python 2 distribution from Subversion Edge, my Python 3 won't start (not even IDLE), instead giving a runtime error messagebox.
If it is set to Python 3, ViewVC doesn't work.
Is there a way to make both work at the same time?
You shouldn't need to set PYTHONHOME at all. Python uses it (if set) to locate its installation. Typically, it should be able to locate it without this variable, as well: by looking at the path name of the python executable, and, failing that, by looking into the registry.
Write a .bat or cmd file that saves the value of the PYTHONHOME env var, invokes ViewVC and wait for it to finish, then restores PYTHONHOME to the saved value.
Have you considered changing the Subversion Edge services to run as a specific user account, and then move the PYTHONHOME environment variable to a user-level variable for that account only? As opposed to a system-wide variable? It seems like it should work.
BTW, the PYTHONHOME variable is added for mod_python to work properly (which is what serves ViewVC). If you can find another way to get mod_python to work, then you could try that.