I have a situation where internally I need to distribute some Python code using Linux packages rather than simply relying on wheel files. This seems to be a solved problem because a lot of Python modules clearly get distributed as .rpm and .deb. It's not completely unreasonable because soon I will have some other modules that are depending on binary applications that are also coming in from packages, and having the system package manage resolve and install all this is convenient. I'm not really in a political position to change that policy, for what it's worth.
I'm still stuck in Python 2.7 here for at least a few more months. Also, it probably helps to know this is a pure Python module that doesn't have to compile any native code. Creating a package itself isn't a problem. In my case, I bandied with the bdist_rpm rule in setup.py, and used stdeb to add a bdist_deb rule. I get rpm and deb files from these, but they seem to be plagued with a problem of making assumptions about paths based on my build environment. I'm building on an Ubuntu rig where Python modules are installed into dist-packages. The rpm package will try to install my module into dist-packages instead of site-packages on a Red Hat rig. I haven't yet tried the Debian package on different rigs, but the stdeb documentation did call out that this likely won't work. I'm wondering first if many of the modules we see in packages right now are actually literally being built using Jenkins or some other CD tool on every major OS distribution. If that's the case then at least I know and I can try to do that. I was surprised that I couldn't easily provide some additional flags. I believe I can specify a setup.cfg that can override the module installation path, and I think I can do a little shell script to just rotate different setup.cfg files through, but I can't help but wonder if I'm even on the right path. -- https://mail.python.org/mailman/listinfo/python-list
