pid file in virtual environments (feature discussion)

[rbscholtus]

Hi ya
The other day I was running a second instance of a script, running in it's own pipenv virtual environment, and noticed that it didn't run because the pidfile was already created. To make that work, I had to provide a path where the pidfile should be stored for the two virtual environments. Seems to me if a script runs in its own virtual environment, it should manage it's own pidfile, and we shouldn't have to make this explicit.

What I'm proposing is that we make a change to the default location for the pidfile. If we are running in a virtual environment, the pidfile should be created in a subdirectory that resembles the name of the virtual environment, based on sys.prefix, e.g. 'C:\\Users\\username1\\AppData\\Roaming\\test-hvyc-pcr or /run/user/username1/test-hvyc-pcr or ...

The effect of the change is that scripts with the same name but running in different virtual environments can run at the same time, without specifying piddir or pidname.

Happy to code that up but wanted to get opinions first.

[trbs]

That's an interesting one... I can see your point.

On the flip side I can see it not being the desired behavior as well for a lot of users.

Say you have a daemon running as part as something you installed in the OS but you also want to develop it locally. Now you want to have only running at the same time but the system Python install and your local development venv would then allow two different daemons to run simultaneously.

Similarly say you have a daemon with some auto-update capabilities and when updating what you do is create a new virtualenv install the new version there then restart the application. That would then lead to a similar case where you could end up having two versions of the same application running since PidFile won't guard against simultaneous runs of the daemon anymore.

My thought it that it would be better that this would be an explicit behavior; something like unique_per_venv=True flag. However this might not gain you much for your use-case other then what you could have done already by using piddir or pidname.