pmxbot IRC Log Viewer

[07:28:22] <pombreda> Hi there :) I need some help with a README ReST that does not display well as a long description on Pypi

[07:28:27] <pombreda> This is it https://github.com/WojciechMula/pyahocorasick/blob/0613580a6254a2eca5ce9f236259ccdb8c33850c/README.rst

[07:28:59] <pombreda> And this is the result https://pypi.python.org/pypi/pyahocorasick

[07:29:32] <pombreda> The ReST validates fine with mgedmin restview in pypi strict mode

[07:30:03] <pombreda> though I just realized that our setup.py kinda truncates the text :|

[07:31:19] <pombreda> mgedmin: with restview, if this validates in pypi strict mode, the whole readme should then be fine on Pypi, right?

[07:34:48] <pombreda> I guess I just need first to avoid truncating my REAME in setup.py :D ... that might have been a previous attempt

[07:38:30] <pombreda> well there you restview rocks and my setup.py sucks: https://pypi.python.org/pypi/pyahocorasick/1.1.2

[07:38:42] <pombreda> all set! Thanks to mgedmin !

[11:18:47] <pombreda> so anyone would have a magic script atht would build wheels for a package with native C code on Windows, Linux and Mac at once and release to Pypi ?

[11:19:35] <apollo13> pombreda: no, but I am using gitlab for that kind of stuff

[11:20:00] <apollo13> ie using their CI runners to automatically build packages and publish into our apt repos, wouldn't be that different for pypi though

[11:20:08] <pombreda> apollo13: hah? they provide a Ci with support for all these three OSses?

[11:20:36] <apollo13> pombreda: well, their runner is a go binary and you have a gitlab-ci.yml were you can define commands to execute

[11:20:51] <pombreda> atm U can get Linux 64 and MacOSX 10.9 from Travis, and Windows ~ 2008 from appveyor

[11:21:08] <apollo13> you can get linux64 from travis?

[11:21:12] <apollo13> I strongly doubt that

[11:21:21] <apollo13> or do they have like centos5 boxes?

[11:21:21] <pombreda> apollo13: I only get linux64 from travis :P

[11:21:39] <pombreda> On an older Ubuntu 12.x

[11:21:51] <apollo13> ah okay, that might work

[11:22:26] <apollo13> pombreda: as for gitlab, I am hosting it in house, not sure what runner specs you get when you run on gitlab.com

[11:22:44] <pombreda> apollo13: got it. I do not want to host anything :P

[11:23:15] <pombreda> been there. Too much fuss to maintain multiple os/arches tests slaves

[11:24:10] <apollo13> hu? it is literally dropping a binary somewhere :D

[11:24:24] <apollo13> but yeah, I get that it can be a hazzle

[11:24:43] <apollo13> I just updated my ci slave to latest windows 10 -- that was pain since you require 20 gb free space

[11:25:10] <pombreda> apollo13: do you know if there is some Pypi way once I made a release (say on Linux and I uploaded an sdist and Linux wheel) to then run on Windows and then Mac just the right setup.py invocation that will only upload to the saem release the Win and Mac wheels?

[11:26:12] <apollo13> no idea, but I'd create all of them and then do twine upload my_files

[11:26:14] <apollo13> https://pypi.python.org/pypi/twine

[11:30:00] <pombreda> apollo13: thanks. sounds decent and what the doctor ordered

[11:31:02] <pombreda> So here is my idea: on a CI build in travis and appveyor I will upload the wheels somewhere, possibly back to Github as release attachements

[11:31:23] <apollo13> yeah some kind of artifact collection sounds sensible

[11:32:05] <pombreda> then I will write a script that will 1. fetch these locally, then 2. build an sdist 3. twine register the release to Pypi and each of the sdist and wheels 4. twine upload

[11:33:04] <pombreda> I need to do this for several natives: pyahocorasick, intbitset and while I am at it bitarray and a few more

[11:33:22] <pombreda> Last time I built seriously some Mac stuffs I had issues though....

[11:34:33] <pombreda> Is there the equivalent of manylinux wheels for Mac? like a manymac? after all building a mac wheel on 10.6 has always worked up to 10.10 for me (but with manual fiddling the metadata on a copy of the 10.6 wheel)

[11:35:48] <apollo13> no idea, my mac knowledge is limited to building dmg packages for our qt app :/

[11:35:55] <pombreda> cross-os distribution of end-user apps is always quite engaged

[11:36:52] <apollo13> well, I currently have msi, dmg, deb and rpm :D

[11:36:57] <apollo13> took quite a while though

[11:37:16] <pombreda> :P

[11:37:30] <pombreda> apollo13: are the build scripts floss? public?

[11:38:16] <apollo13> pombreda: kind of inbetween I fear, but if you are interested I can send them to you -- it is mainly cmake + cpack though, not sure it would help in your situation

[11:38:18] <pombreda> this would be for https://github.com/nexB/scancode-toolkit

[11:38:42] <pombreda> apollo13: probably not. cmake would be one more stuff to worry about :P

[11:38:46] <pombreda> thanks anyway!

[11:38:49] <apollo13> cmake is great

[11:38:54] <apollo13> well, kinda at least

[11:38:59] <pombreda> yes, but one more tool to embrace

[11:39:22] <apollo13> wouldn't make much sense for a python app anyways imo

[11:40:14] <pombreda> well mine is Python + Python natives + some bare natives (either used via ctypes like libarchive or as bare command line spawns otherwise)

[11:40:36] <pombreda> ** sigh**

[11:40:38] <apollo13> hehe

[11:40:46] <apollo13> live choices ;)

[11:41:04] <pombreda> what do you mean by this?

[11:42:35] <apollo13> ah, would have been life choices, I always mix those two up, also COMPUTERS, if that helps ^^

[11:43:01] <pombreda> :P

[11:44:04] <pombreda> what would be the most decent Python client for the latest Github API? so I craft realease and upload my CI-built wheels there before twining them to Pypi?

[11:44:19] <pombreda> *so I can craft a release

[11:44:59] <apollo13> I was using https://github.com/PyGithub/PyGithub with success

[11:45:36] <pombreda> cool, thanks. too many choices for me on Pypi otherwise !

[11:48:06] <apollo13> my usage was limited to auditing webhooks for an orga, so ymmv

[16:09:07] <dstufft> pombreda: you don't really need manylinux for OS X, there is already a single, stable ABI for OS X using the SDK version

[16:10:09] <dstufft> which is similar to that of manylinux, other than what libraries are available to link, if you build for 10.6 that'll work for >= 10.6 as long as you only link to system provided libs

[16:11:03] <dstufft> if you need something newer than that, you can build for 10.7 or 10.8 or whatever, you can even release both if there's some optional feature that is compiled on newer OS X's so that pip will prefer the newer one if possible, or if not use the older one.

[16:11:19] <dstufft> of course, if you depend on a library that isn't part of the base OS in OS X, you'll need to bundle it or static link it

[16:16:13] <pombreda> dstufft: hey, thanks for chiming in!

[16:17:52] <pombreda> dstufft: and for non bas OS libs, eventually relocate the dylib... which is semi hellish, but I have a recipe for that

[16:17:58] <pombreda> *base

[16:19:44] <pombreda> I also need to relocate other dylibs when loaded with ctypes: I have a template there: https://github.com/nexB/scancode-thirdparty-src/blob/master/libarchive/libarchive-macosx-build.txt

[16:20:06] <pombreda> and there again it must be built on 10.6 (I scanvenged an old 10.6 laptop for that)

[16:21:21] <pombreda> dstufft: so you reckon there is no way to build a Mac wheel on 10.9 (which is the version of Travis) that would work on older versions?

[16:21:29] <dstufft> pombreda: I don't think you need to build it _on_ 10.6, you just need to tell OS X to link against 10.6 SDK

[16:21:33] <dstufft> but I'm not an expert

[16:22:53] <pombreda> neither am I :) any mac guru out there?

[16:26:22] <tdsmith> you need to have a copy of the 10.6 sdk handy though

[16:26:53] <tdsmith> so i think it's not as simple as setting MACOS_DEPLOYMENT_TARGET or whatever

[16:28:06] <pombreda> well, I guess I will have to digg up that old 10.6 laptop, all preconfigured. thank you tdsmith !

[16:28:33] <pombreda> it is not like I have tons of options on Travis: https://docs.travis-ci.com/user/osx-ci-environment/

[16:29:00] <pombreda> and that's the only FLOSS-friendly Ci I know of that supports OSX

[16:31:52] <tdsmith> an alternative is not supporting 10.6 :p

[16:33:31] <pombreda> indeed.

[16:33:34] <pombreda> may be the way

[16:39:11] <pombreda> well https://circleci.com also has free plans for OSX for FLOSS too

[17:40:25] <pombreda> This is not working too badly after all. I must have a good day: we have liftoff with rather minimal efforts : https://github.com/pombreda/thirdparty now builds wheels on Linux/Mac/Win

[17:40:30] <pombreda> https://ci.appveyor.com/project/pombreda/thirdparty/ for win and https://travis-ci.org/pombreda/thirdparty/ for Linux and mac

[17:41:03] <pombreda> mgedmin: thanks again for restview ! this is a godsend for my fat finger typos when writing ReST!

[17:42:29] <pombreda> next step is upload these wheel to some other places whe I can get to them.... before sending them to Pypi... any suggestions? bintray? github release? sourceforge scp?

[17:42:40] <pombreda> dstufft: what do you use? :P

[17:46:22] <pombreda> next: I also need to find a way to build win64 on Appveyor ... and I probably use the manylinux docker setup to build manylinux wheels instead

[17:53:32] <pombreda> well I will give a shot at bintray for a change

[17:54:36] <tdsmith> bintray's been a good solution for homebrew

[17:57:10] <pombreda> tdsmith: thank you for the moral support :P

[18:52:20] <apollo13> pombreda: cause the work week already has > 40 hours? :D

[18:52:55] <pombreda> apollo13: you are from another planet for sure :D

[18:53:20] <pombreda> just kidding

[18:54:12] <apollo13> I laready had fun this weekend upgrading everything to the latest win10, so much for poor life choices :D

[18:56:19] <pombreda> that I can understand!

Log file Viewer

Help | Karma | Search:

#pypa logs for Sunday the 7th of August, 2016