Creating a virtualenv on a shared filesystem should work, though end users would still have to activate it themselves. Of course, all a virtualenv really does is to symlink some executables to sit at the front of your PATH and to make sure the virtualenv is in your PYTHONPATH – you may be able to write scripts that do this manually.
There are a couple of gotchas you should be aware of before choosing this deployment method:
- Shared file systems are often comparatively slow. This will make any
import more costly.
- Anything that may be executable must not be writable by other users, or that could be abused to engineer a wormable malware against your organization. Defense in depth is important.
- CPython caches the compiled bytecode in
*.pyc files. As the directory must not be writable, these files should be created during installation. But these files are only useful if everyone uses the same Python version. If you can deploy a specific Python version, you could also just deploy your software directly.
- If your end user systems have different operating systems or CPU architectures, dealing with native libraries is more difficult. You can no longer offer a single virtualenv, but must offer one per OS/architecture combination. This also makes it more difficult for end users to set up their system correctly.
Since you still have to at least deploy Python and virtualenv setup scripts to end users, it really might be easier to use those deployment mechanisms for your Python software as well.
Also consider whether running the software on end-user systems is appropriate. Web-based software gives you a lot more flexibility about deployment. For example, in the Data Science community Jupyter notebooks are a common tool. You can install Jupyter locally via
pip. But an organization may prefer to host them on a beefy server with a guaranteed-working set of dependencies – a win for everyone involved.