Package for Debian (.deb) #56
Conversation
Codecov Report
@@ Coverage Diff @@
## master #56 +/- ##
=======================================
Coverage 99.19% 99.19%
=======================================
Files 8 8
Lines 874 874
=======================================
Hits 867 867
Misses 7 7Continue to review full report at Codecov.
|
|
As debian users ourselves it's a really nice addition. My only concern is maintenability over time: are you aware of any way to test package building on travis? |
|
Glad to hear that it's an appreciated addition. I've never tried building the packages through Travis, but based on some quick reading it seems to be doable without too much trouble. I'll give it a shot in the near future and report back. |
|
@rgson that would be awesome! |
|
@yakky So I've actually had a chance to test this out already and it works just fine. However, a decision must be made before I can propose the change. The default Travis container does not have the .deb build dependencies installed. It's easy enough to install them, but there seems to be two approaches to how that's done. The first approach uses sudo to installs the dependencies defined in the debian/control file, as usual. Unfortunately, Travis only allows sudo access on the slower VMs, leading to a rather annoying delay before each new build is started. The second approach is sudoless, but requires the build dependencies to be listed in the .travis.yml file (to grab the packages off of Travis' apt whitelist). A build starts almost instantaneously like they currently do, but the build dependencies are duplicated across two files, which is of course suboptimal from a maintenance perspective. Personally, I lean towards the second (sudoless) approach. I expect the build dependencies to be pretty much invariable, leading me to believe that the delayed builds would be the bigger nuisance. Ultimately it's your decision, though. |
|
@rgson thanks for taking time to investigate. The second solution looks perfectly sensible. build-deps are not going to change often and they are going to be spotted quickly because of the test failures |
|
@rgson I saw the failure on travis on the package building tests |
|
@yakky Huh, that's surprising. My fork builds fine on Travis. 🤔 I'll investigate it tomorrow. |
|
I'll fork this and I'll give it a try myself |
|
@yakky The reason it works on my fork is that I forgot to pull the new upstream commits. 🤦♂️ Commit b2ea550 turns the runtime dependencies into build dependencies. Indeed, pyjwkest and python-dateutil (and some others) should be declared as build dependencies then. Unfortunately, it's not as straight-forward as one would wish. Firstly, pyjwkest is not available in the Debian/Ubuntu repositories. To formally satisfy that dependency, I'd have to build .deb packages for that, too. It's actually not strictly required at build-time since the imports are conditional, but it really should've been specified as an install-time dependency already (I guess pybuild doesn't understand the git-based dependency in requirements.txt), leading back to the same problem. Secondly, python-urllib3 (used through python-requests) is too outdated on Travis' version of Ubuntu (14.04). So while that dependency can be satisfied on newer distros, it won't work on Travis. Of course, working versions of the dependencies can be installed through pip the same way it's done for the tests, but the dependencies listed in debian/control would still be seen as unfulfilled. I'll probably end up making some minor changes to turn pyjwkest into an optional dependency by disabling the affected features if it's absent. I believe it should be fairly easy, seeing how I've been using python-taiga without pyjwkest for a while without even realizing. That would save me, or at least postpone, the grief of packaging yet another module. The python-urllib3 problem ought to be solvable by pulling a newer version from a non-default software repository. That would probably require the builds to run on the slower VMs with root privileges, though. If you have any other suggestions, I'm all ears. |
|
@rgson
|
|
@yakky Good to know that I've not missed anything regarding pyjwkest. That should be easily fixed then. As for apt sources, it's indeed possible to add any of the whitelisted sources, but no others. The only whitelisted source with a newer version of python-urllib3 seems to be Debian's unstable version (debian-sid). Adding that will, rather unsurprisingly, break the upgrade. Without apt pinning it seems impossible to grab the newer version from there. I'll try to find a work-around. |
|
@rgson feel free to switch to the non-container version, if this makes the tests easier |
|
@yakky There, an up-to-date version which passes on Travis. 🎉 I did have to move to the non-container version to get the dependencies sorted. The difference in runtime is much lower now than during my previous attempts, though, so it's probably not as big of a deal as I previously thought. As a bonus, that got rid of the duplicated dependency list in .travis.yml (well, except for the modules that need updates from xenial). |
|
@rgson this is just awesome 🙇♂️ thank you for your hard work |
I've added a basic configuration to build
.debpackages of the module for Debian-based systems.The configurations is not complete enough to get accepted into the official Debian repository, but it ought to suffice if someone wanted to set up a PPA, for example. Personally, I need the
.deb-packaged version to be able to distribute the module in a particularly Debian-centric environment.Pybuild does the heavy lifting based on your existing
setup.pyfile. A single command, which I've encapsulated in the Makefile, is enough to build the packages for both Python 2 and 3.If this is merged, the Maintainer field (line 4 in
debian/control) should probably be changed to (one of) the repository maintainers from here.