Where is the appropriate place to host Python virtual environments according to the Linux file system hierarchy standard?

Question

As the title says, what is the technically correct place to store Python virtual environments on Linux operating systems according to Linux FHS?

Another way is indicated that allows you to get a clear answer: Is it “technically correct” to separate the location of the Python virtual environment from the data files that you serve?

Note: This question is different from the closest, already asked question, which I could find , since virtual environments contain libraries, binaries, header files and scripts.

As an additional complication, I prefer to write code that supports services available on the Internet. However, I do not see this as a significant difference between my needs and scenarios in which service consumers are other processes on the same server. I mention this detail in case my comments replies include "web dev" content.

For reference, I use the following documentation as a Linux FHS definition: http://www.pathname.com/fhs/pub/fhs-2.3.html

I do not believe that the popular virtualenv-wrapper script offers the correct action, since by default it stores virtual environments in the user's home directory. This violates the implicit notion that the directory is intended for user files, as well as the assertion that “no program should rely on this location”.

From the root level of the file system, I lean towards /usr (general read-only data) or /srv (Data for the services provided by this system), but this is where I can hardly decide further.

If I agreed with the decision of my reverse proxy, that means /usr . Nginx is usually packaged to log in to / usr / share / nginx or / usr / local / nginx, however / usr / is supposed to be mounted read-only according to FHS . I find this strange because I never worked on one project in which development was so slow that "unmounting as soon as read / reboot with writing, unmounting / reloading as soon as read" was considered worthy of work.

/srv is another possible location, but is indicated as “location of data files for a specific service”, while the Python virtual environment is more oriented to libraries and binaries for what provides the service (without this differentiation, .so files will also be in srv) . In addition, several services with the same requirements can share a virtual environment that violates the “specific” details of the description.

I believe that part of the difficulty in choosing the right location is that the virtual environment is a “medium” that consists of binary files and libraries (almost like its own small hierarchy), which makes me feel like somewhere under /usr is more conditional:

 virtual-env/ ├── bin ~= /usr/local : "for use by the system administrator when installing software locally" ├── include ~= /usr/include : "Header files included by C programs" ├── lib ~= /usr/lib : "Libraries for programming and packages" └── share ~= /usr/local 

Based on my assumptions and thoughts: consider a common Nginx script acting as a reverse proxy for a Python application. Is it correct to place the virtual environment and source code (for example, application.py) under /usr/local/service_name/ when using /srv for files that change more often (for example, "static" assets, images, css)?

edit: To be clear: I know why and how to use virtualenvs. I am in no way confused with the layout of the project or working in a development environment.

Answer 1

As the title says, what is technically the right place to store Python virtual environments for Linux operating systems according to Linux FHS?

Keep in mind that Linux FHS is not a standard; it is a set of recommendations. LSB is just the standard, which is just a set of rules that make Linux support easier.

/run , /sys , /proc and /usr/local are not all part of LFS, but you see them on most Linux distributions.

For me, the explicit choice for hosting virtual environments is /opt , because this location is reserved for installing additional software packages .

However, on most Linux distributions, only root can write to /opt , which makes it a poor choice, since one of the main goals of virtual environments is to give up root.

So, I would recommend /usr/local (if it could be written as a regular user account), but there is nothing wrong with installing it in your home directory.

Another way is indicated that allows you to get a clear answer: "Is it technically correct" to separate the location of the Python virtual environment from the data files that you serve?

I'm not sure what you mean by “data files that you serve”, but here are the rules for virtual environments:

• Do not put them in the source code.
• Keep a list of installed packages and put it in version control. Remember that virtual environments are not entirely portable.
• Keep your virtual environment separate from source code.

Given the above, you should keep your virtual environment separate from the source code.

consider a common Nginx script acting as a reverse proxy for a Python application. Is it correct to place the virtual environment and source code (for example, application.py) in the / usr / local / service _name / while directory using / srv for more dynamic files (for example, "static" assets, images)?

Static assets are not dynamic files, I think you are misleading the conditions.

In any case, you should do the following:

• Create a user account to run this application.
• Place the application files in a directory that is managed by this user and this user. This is usually the directory /home/username , but you can do this /services/servicename . Place the virtual environment as a subset of this directory in the standard naming format. For example, I use env .
• Put your static assets like all media files, css files, etc. to the directory that is read by your front server. Thus, you usually make the www directory or the public_html directory.
• Make sure that the user account created for this application has write access to this resource directory so that you can update files. The proxy server must not have permission to execute in this directory. You can accomplish this by changing the directory group in the same way as the proxy server user. Given this, I would put this directory under /home/username/ or /services/servicename .
• Launch the application using the process manager, and make sure that your process manager switches the user to the one that was created in step 1 when you ran your application code.

Finally, I cannot stress enough of this DOCUMENT OF YOUR PROCESS and AUTOMATIC INFORMATION .