Submit for PyPI

[dashesy]

Do you plan to submit the package for PyPI (Python Package Index)? It will bring in many more Python programmers in the scientific computing community, who otherwise are less willing to compile from the source.

[davisking]

I'm not going to but you are welcome to do it if you are interested :)

[dashesy]

Thanks for the nice project!
I am adding a setup.py here it works with bdist_egg, bdist_wheel, build, ... but not sdist yet (have to put source files above setup.py during build).
Will do a PR when everything is ready. I can also submit your package for PyPI with your permission, if you do not want to do that yourself or do not have time, but it should not be that difficult with a working setup.py in hand.

[davisking]

Sweet. Let me know when it's ready and I'll try it out.

Is submitting to PyPI very involved? I'm not at all familiar with any of this stuff.

[dashesy]

Frankly I have not done that myself, that requires having a worth-while package and I do not have one :)

According to the documents here once initial channels are set up and ready, the package owner can do e.g. python setup.py sdist upload for any new release.
After that users can use pip install dlib. For users on Windows and OSX having a wheel channel (bdist_wheel) helps them not needing any compilation from sources (setting up cmake, ...), for Linux users sdist channel is fine.

[davisking]

Yeah I've read a little about PyPI but always got the impression it wasn't going to work well for binary packages. I also get emailed constantly by people who have weird different types of python setups (e.g. system installed python vs. mac ports vs. brew vs. anaconda vs. whatever) and they are all incompatible with each other at a binary level. Is pip really going to deal with all that somehow? Does it have a compile farm setup that creates binaries for all the different python configurations?

[dashesy]

The source distribution (sdist) is exactly like compiling from source.
Wheel packages are based on a new standard and distinguish different ABI. For example when I make a bdist_wheel I get this dlib-18.17-cp27-none-linux_x86_64.whl, which is a wheel for Linux on a 64bit Python2.7.
Most of PyPI is now converted to wheels, and in my limited interactions with binary wheels I have not faced any issues. There used to be some issues, but mostly they are sorted out now.

There is no compile farm, the package owner compiles the binaries, and signs the package for whatever arch/OS they care :) the rest of users will get sdist and need to have the tools for local compilation.

[dashesy]

As per discussion about continuous integration, I was not aware of it but apparently there are free compile farms that also integrate with GitHub. wheelhouse-uploader will make CI and building for multiple platforms very simple, so that package maintainer does not need to compile for all platforms too. It is used in many OSS on GitHub to integrate with Travis CI that will even run tests on different platforms before a release is ready!
Continuous test on multiple platforms and setups, together with more test suits, will make sure code quality remains high.

[davisking]

I submitted dlib to PyPi. There are 4 wheel files for windows and a sdist. I had to tweak a few things but otherwise it seems like it's all working. So pip install dlib should now be working. Try it out and let me know what you think.

[dashesy]

Thanks, that is great news! when I started application, it complained about Boost Software License being unknown, which I created an issue here but, yes now pip install dlib now works!

[davisking]

Sweet. Thanks again for setting this up.