Introduce continuous deployment

[mristin]

Hi @safijari,
I opened an issue to discuss the continuous deployment in a separate thread from the pull request #1 .

    If you're interested in incorporating this and having CI set up to build and publish the wheels automatically please comment here and I can move this PR forward with those changes.

That would be great! Can we maybe do that in a separate pull request?

Sure. I've had decent luck with AppVeyor (e.g. https://github.com/safijari/apriltags2_ethz/).

I'd need you to set up your pypi credentials as a secret in appveyor or whatever we end up using. Either that or I'd need to be a collaborator for the lanms package on PyPI.

I looked up what we did with the other Parquery projects. We had quite a few situations where multiple commits resulted in a single version bump (usually because we want to test something or wait a bit before releasing).

I could introduce a script release_to_pypi.py into the repository root that just builds and packages everything and sends it over to pypi. It's a single manual step, but this step should probably always remain manual anyhow.

Please let me know what you think.

[mristin]

P.S. since you have more experience with building the wheels, what is the exact command that you execute when building & packaging? (We usually distribute the source distributions; Dominik Walder worked on EAST detector during his internship.)

[safijari]

Hey @mristin. My personal workflow around versions and releasing is keeping these things manual, either using git tags or github's releases thing. I guess git tags can still collide but I usually work with a small team where we can coordinate.

For wheels the base command is python setup.py bdist_wheel but when you're releasing something like lanms you need to maintain binary compatibility and packaging needs to happen separately for each python version. To achieve this I try to follow the manylinux1 approach which involves building the wheels in CentOS 5 (they're moving to 6 now) and then using auditwheel which in turn uses patchelf to make a self contained wheel (a.la opencv or numpy). the package cibuildwheel can automate most of this in CI and works well with both appveyor and travis.

This is an example of it being used with appveyor https://github.com/safijari/apriltags2_ethz/
This one does travis https://github.com/safijari/open_karto
Both use a custom container for building that's defined here https://github.com/safijari/manylinux-x64 (it has boost, eigen, and opencv preinstalled).

Hope that gives some clarity. I'll try to work on this and the other issue over the weekend.

[mristin]

Hi @safijari ,
Let's go with travis since we already use it for other open source projects. Other than that, I think you are more experienced in these regards, so please go ahead and let me just double-check the pull requests before merging them. Thanks again for all the contributions!