As an SRE/ops (and I'm talking some years ago) it was often a pain point, especially with devs with a "works on my machine" attitude ; you would never get the exact requirements from them, I even saw a team of 2 who worked together with different versions of stuff on their respective machines. I also worked in some "offline" environments where once in prod you cannot pull anything from the internet, and you cannot install a compiler too, so it's quite hard to ship because some pip packages require to be built.

I found a way using (can't remember the tool name) which if you loop through the imports and gives it to the tool you get the package name, then I would build wheels to have all binaries and build a container or a VM with all that's needed, thus working completely around python package managers. This was a good enough workflow for the kind of deployment we needed.

Jupyter added a layer of complexity, I deployed it alongside RStudio as browser IDEs in docker swarm. Everybody wants a different set of deps and versions, so you have to keep track of everything, and also people may use things just for development that must not be shipped to prod, so you have to keep track of that too. Also some would develop notebooks on windows and expect them to work in linux VMs/containers and even in prod.

Nowadays devs ship container images anyway through a CI so it is less of an issue. In this era docker was far from being the de-facto everywhere, some people were still afraid of this, security didn't like it, etc.