For the context, this is my first stroll down the road of packaging for python. It does not feel like a stroll, though, more like stumbling at different concepts and tools, with changes of those over time, support for different python version on different OSes… It took me off guard, to be honest.
If your aim is to distribute a wheel, the best you can do is put the copies of your binaries directly alongside the extension modules that use them. This should be supported on all platforms for your package in isolation.
Yes, this is the general idea, to go with something that could be installed with known tools like
pip. I do have a “single package distribution” case covered for all three OSes. As soon as I add the second package to the mix, that needs to have access to first package’s support binaries their location is a major issue for me to tackle. I did miss the part of using
pip install . and not
python setup.py install as @uranusjr pointed out. Hopefully matters get better defined in terms of locations when going this way.
Placing the supporting binaries next to the extension module seems the most straightforward path. I guess I wanted to make a distinction between the support binaries and extension just to start complicating my life. I also have made that work, but I fear that the solution is on weak foundations because I’ve see the location of package change (
.egg vs. no
.egg folder). Again, I need to look into
pip install ..
When you know that other packages are likely to exist in user environments that will conflict with yours…
The binding I’m trying to create and distribute can be considered non-existent at this point in time, but I see where the problems may arise by assuming that will not change in the future. Nevertheless, there does not exist an ‘official’ native packaging of the library/code I’m providing binding for, and also the upstream authors are not thinking of providing one (it is a couple of C++ files that are usually dropped into the end project folder and compiled into the final binary.) Of course, it is possible to have those compiled as a shared library and used as such, but the use cases are few and far in between; one of them seems to be a python binding, though. That being said, the likelihood of end user to have such library already installed, are very small, IMHO. At the same time I do not want to ask the user to install this shared library on her own. I also feel uneasy to place the library in a some non
site-packages venv folder where it may conflict with potential future bindings.
I would also like understand a bit more how to approach the distribution of the headers (and possibly static libraries) from which the support binaries were built. Should a developer that needs to use those as dependencies in her project, find them in the wheel? Would they be normally distributed with the binary wheel? Or is there a concept of
src packages that I want to look into?
Currently I have two packages I’m working on, with one depending on another, and the support sources and binaries on hand. At the moment the dependent package build needs to have the dependee package in
site-packages. I think that is OK, because I do not want to require other developers to deal with the dependee package source compilation and all to get their package built.