My feeling is that virtualenvs are really a developer tool.
They’re vital for developers because they let you work in isolation: it works on my machine! syndrome is almost always the result of you relying on something without realizing that you need it – and then shipping tools off to people who don’t have it, whatever “it” is. If you work in a virtual env you can be 100% sure you know what’s there. I’ve probably got 20 virtualenvs on my machine right now – but when I send stuff to users it’s a plain of bucket of files. I’m pretty leery of actually distributing them to non-technical users although you could probably manage a system that spun them up from scratch using bat file or the like.
So, I love virtualenvs as a disciplined way to track what you actually need for your tools. But, for users, I prefer them a single, complete environment that they don’t have to touch. Most artists don’t want to manage a python ecosystem and thus are not very good at it – and often the ones who are interested in trying to do it end up breaking your stuff by doing something that seems innocent, like installing a package which breaks your tool on that one machine and isn’t visible without hours of version-sleuthing.
I’m currently working on a method for building a complete environment using pipenv on the developer side and a build script that takes a vanilla Python environment, clones it, and then uses pipenv and Pipfiles to build a working distribution. That whole thing gets shipped to users so we have (in theory!) completely self-contained, 100% reproducible environments. However I have the luxury of relying on an inhouse tool for distributing the bits, so I don’t have to try to be economical about transfer rates and so on.
The main hassle factor so far has been that pipenv – like any virtualenv based strategy – depends on developers creating fully specified packages, like what you see on the PyPi . That means you have to wrestle with the horror that is
setup.py, which is a pain in the ass. I’m still experimenting to find the right granularity for the pieces – I like doing lots of smaller projects so that the version control history is clear and useful but the setup.py tax may push me towards a smaller number of bigger chunks.
The “right” way to get the actual bits into the hands of users may really be something you want to negotiate with your IT folks instead of solving it on your own – they may have tools or options you don’t know about. It’s certainly worth asking. The mechanics are really not too important, though – the big thing is to decouple the way you get the bits to your users from their user experience. Whether it’s a .bat file or a launcher application or something built in to another tool, you want the average user’s experience to be simple and convenient (and very hard to bypass!) – if it becomes too time consuming or too manual they will quietly opt out, and then you’ll spend lots of time debugging a ‘problem’ that you know is solved before you realize that user X is on a two-month-old version of the tool.