Log file Viewer

[00:20:21] <_habnabit> well, i'm trying out pex with newer setuptools, but iirc it'll fail because pkg_resources validates deps when you start the program

[00:20:29] <_habnabit> maybe i'll have to switch to python -m pex

[00:20:32] <_habnabit> what a shitshow

[00:26:01] <glyph> _habnabit: speaking of shitshows!

[00:26:15] <glyph> dstufft _habnabit : whyyyy is 'tox' putting 'twisted==15.4.0' on the command line here: https://travis-ci.org/rackerlabs/mimic/jobs/94533886

[00:26:23] <glyph> it doesn't do that when I run tox locally

[00:26:57] <dstufft> glyph: different versions of tox?

[00:28:04] <glyph> dstufft: no, the first thing I did in the change that's testing is install the right version of tox

[00:28:09] <glyph> unless it's like a $PATH issue or something/

[00:28:37] <dstufft> I'm not sure then, the tox channel might know better

[00:29:10] <glyph> yeah even if i switch to a version of tox itself running under py26 it doesn't do it locally

[00:29:46] <glyph> dstufft: okay #tox is for https://tox.chat

[00:29:52] <glyph> dstufft: so where do I go for tox

[00:30:09] <glyph> dstufft: remember when I said that you shouldn't put stuff into ~/Library/Caches/Pip; this is why

[00:30:30] <dstufft> we do it anyways >:]

[00:31:02] <dstufft> #pylib is the channel though

[00:33:32] <glyph> oh nice, I am now being penalized for debugging this too much:

[00:33:33] <glyph> Could not install requirement treq==15.0.0 from https://github.com/twisted/treq/tarball/9196ee2136cda472134e4d454d3aeab6cded7f54#egg=treq-15.0.0 (from -r /home/travis/build/rackerlabs/mimic/requirements/production.txt (line 26)) because of HTTP error 429 Client Error: Too Many Requests for URL https://github.com/twisted/treq/tarball/9196ee2136cda472134e4d454d3aeab6cded7f54#egg=treq-15.0.0 (from -f)

[00:36:11] <dstufft> glyph: lol

[00:37:20] <jessamynsmith> glyph: that sucks

[01:06:16] <glyph> dstufft: augh now this https://travis-ci.org/rackerlabs/mimic/jobs/94539520#L2547

[01:06:20] <glyph> dstufft: why do I even try to pip things

[01:06:54] <dstufft> glyph: you're using dist: trusty aren't you

[01:07:28] <glyph> dstufft: this is like... pypy on OS X or something?

[01:07:35] <dstufft> oh

[01:07:42] <dstufft> how the fuck did you get that error on OSX

[01:08:08] <dstufft> every time I've seen that error it's because Debian patching

[01:08:09] <glyph> dstufft: it's in a *venv* on OS X

[01:10:58] <glyph> dstufft: oh I might be doing some real dumb stuff here

[01:11:32] <glyph> dstufft: there's some virtualenv and there's some pyenv and then there's some other stuff

[01:11:52] <dstufft> are you using python -m venv at all

[01:13:17] <dstufft> glyph: I gotta go for a bit, but somehow your pip install is real confused or something

[01:13:21] <glyph> dstufft: this is really confused; I am installing python from pyenv

[01:13:34] <glyph> dstufft: I am not quite sure how you tell tox which 'py27' to treat as py27

[01:13:52] <dstufft> it's whichever python ``python2.7`` is

[01:14:04] <dstufft> adjust your path if you need to change it

[01:14:33] <glyph> dstufft: does "pyenv global" adjust your path accordingly?

[01:14:47] <dstufft> it does if you do the init

[01:15:22] <dstufft> eval "$(pyenv init -)";

[01:15:30] <glyph> right ok

[01:15:35] <glyph> dstufft: yeah let me go sort this out

[01:15:45] <dstufft> gonna go now, hope you get it sorted!

[08:08:38] <mgedmin> uh oh assert tag == supported_tags[0] fails in bdist_wheel while building cryptography

[08:19:55] <ionelmc> mgedmin: wasn't that fixed in latest wheel?

[08:20:10] <ionelmc> 0.26 or something

[08:21:42] <mgedmin> "py35 installed: wheel==0.24.0" ha ha thank you letsencrypt's tox.ini

[08:22:12] <mgedmin> no wait the version number is not pinned anywhere

[08:22:18] <mgedmin> why does it install wheel 0.24.0? o.O?

[08:22:46] <mgedmin> does virtualenv bundle 'wheel'?

[08:23:13] <mgedmin> yes, yes, I know, "use the rewrite"

[08:24:29] <mgedmin> ha ha https://github.com/pypa/virtualenv/blob/develop/docs/changes.rst "upgrade wheel to 0.26" is in 14.0.0 (unreleased)

[08:31:23] <ionelmc> mgedmin: why are you surprised :)

[08:36:16] <mgedmin> BUNDLING IS BAD, 'MKAY?

[08:36:40] <mgedmin> at the moment I very strongly empathise with downstream distro packages who unbundle shit

[08:36:48] <mgedmin> and get hate from upstreams

[08:39:29] <ionelmc> flat is better than nested haha

[08:52:38] <ronny> mgedmin: the problem is that there is no propper tooling to manage bundle/unbundle, and upstreams need to work and downstreams break the world

[08:53:52] <ronny> mgedmin: py.test also re-bundled pluggy because python cant handle multi versioned modules and api versioning in a sane way

[08:57:41] <mgedmin> are there languages that can?

[09:36:04] <ionelmc> mgedmin: still, hard not to recognize the actual problem is the old wheel, and not the way is installed (bundling)

[09:37:30] <mgedmin> problem: pip install -U pip setuptools virtualenv tox wheel --> to get latest tools; run tox --> see those assertion errors scroll by

[09:37:38] <mgedmin> because tox uses virtualenv and virtualenv bundles old wheel

[09:38:01] <mgedmin> and tox doesn't pip upgrade wheel inside the virtualenvs it creates because why would it ever even know those virtualenvs have a 'wheel' package inside?

[09:38:16] <ionelmc> no one wants to hear it, but that wouldn't be a problem is there was some proper maintenance

[09:38:31] <ionelmc> and frequent releases

[09:38:43] <mgedmin> oh, and this wheel build failure isn't fatal, it just means pip disables wheel caching for that one time so tox takes longer to run

[09:42:26] <ionelmc> mgedmin: really?

[09:43:26] <mgedmin> afaiu when pip install tries to build a wheel and fails, it then tries a regular setup.py install

[09:43:48] <mgedmin> so cryptography gets compiled twice

[09:43:52] <mgedmin> good thing I have ccache

[14:42:32] <dhellmann> dstufft: hey, is there already a package for validating pep440 version numbers? even something inside pip I can reuse would work, I just want to add a simple validator to the openstack release request pipeline

[14:43:38] <mgedmin> dhellmann, https://packaging.pypa.io/en/latest/version/

[14:44:29] <dhellmann> mgedmin : perfect, thank you!

[15:54:35] <mhils> hi. Is there a way to require a minimum version of setuptools when I pip install something?

[16:00:31] <ronny> mhils: not yet a sane way

[16:00:44] <ronny> mhils: the build tool pep will eventually properly allow it

[16:01:13] <mhils> ronny: thanks. :-/

[16:01:35] <mhils> looks like we can't ship wheels then :(

[16:04:53] <ronny> mhils: oh, a wheel can have a install requires for recent setuptools

[16:05:07] <ronny> mhils: i thought you wanted something for a setup.py and setup requirements

[16:05:37] <ronny> mhils: if you build a wheel with a modern setuptools version and have a very modern setuptools version in install_requires, then things just work

[16:05:39] <mhils> I want a single setup.py that (1) handle `pip install -e .` and `setup.py bdist_wheel`

[16:06:01] <ronny> mhils: for that you dont even need modern setuptools

[16:06:22] <ronny> mhils: what is the use case you want, its very unclear

[16:06:40] <ronny> for making wheels, just make a veritualenv with a modern version of setuptools/wheel

[16:06:58] <mhils> https://github.com/mitmproxy/mitmproxy/commit/51bd98d5b17e3d8d49f12a7f63545e8dac61959a#diff-2eeaed663bd0d25b7e608891384b7298R71

[16:06:59] <ronny> and for pip install -e . things should be okish as well

[16:07:15] <mhils> ':python_version < "3.4"' breaks travis if it tries to pip install.

[16:08:02] <mhils> which seems to be a setuptools bug: https://bitbucket.org/pypa/setuptools/issues/380

[16:08:53] <ronny> mhils: so update setuptools first?

[16:09:02] <mhils> Using the latest setuptools etc., everything works fine; but we have lots of users on some old LTS releases :-/

[16:09:03] <ronny> travis is outdated on both pip and setuptools

[16:09:19] <ronny> and for lts users provide distro packages

[16:10:19] <mhils> eek, that's exactly the maintenance I wanted to avoid :P

[16:12:44] <mhils> ronny: thanks for the help. I'll dig into that and see how we can fix it best :-)

[16:12:54] <ronny> i have a 2 year plan for completely automating that, but its on volunteer time atm so no promises

[16:13:17] <mhils> :)

[16:15:27] <ronny> mhils: after i get to the point where py.test releases are automated, i'll look at automating getting it to distros

[16:16:01] <mhils> ronny: awesome!

[16:16:43] <mhils> we currently just provide OSX and Windows binaries as 'pip install' works good enough for our use case (at least we are getting very few complaints), but proper distro packages would be great.

[16:21:07] <ronny> mhils: it'll need help at some point, debian and ubuntu are insane for example, and red hat is kinda painfully stable

[16:24:53] <mhils> ronny: you happen to know projects which switched to just providing freezed binaries on linux?

[17:49:08] <ionelmc> mhils: freezed binaries?

[17:49:21] <ionelmc> and by projects you mean libraries or applications?

[17:49:26] <mhils> applications

[17:49:43] <mhils> freezed as in http://docs.python-guide.org/en/latest/shipping/freezing/

[17:50:07] <mhils> i.e. we have self-contained executables.

[17:51:37] <nanonyme> Frozen binaries for Linux is pretty useless. The main point of freezing is that you ship a Python interpreter. Linux typically already has one

[17:51:58] <nanonyme> Also ABI issues make it pretty much PITA anyway

[17:53:41] <mhils> nanonyme: well, you don't have to deal with the OS Python, which I'd say is a win. :-P

[17:53:55] <nanonyme> mhils, you do

[17:54:13] <mhils> why that?

[17:54:13] <nanonyme> mhils, you need to make OS-specific binaries and OS-version-specific binaries for Linux typically

[17:54:22] <nanonyme> It's less pain to just use the platform interpreters

[17:54:52] <nanonyme> There's no ABI guarantees basically in the entire operating system

[17:55:07] <mhils> we don't have linux binaries yet, but as I see it, the ABI is backward-compatible?

[17:55:34] <nanonyme> Eh, even libc ABI is not backwards-compatible as far as I've understood...

[17:55:50] <nanonyme> Windows is *easy* in this respect

[17:56:01] <mhils> yes, Windows and OSX work wonderfully fine

[17:56:17] <mhils> (except for the fact that pyinstaller is really really buggy oftentimes)

[17:56:45] <mhils> I didn't experiment with the Linux binaries yet, but according to https://github.com/pyinstaller/pyinstaller/wiki/FAQ the ABI is backward compatible.

[20:05:15] <h3ll0> ubuntu@ubuntu:~$ pip3.4 --version

[20:05:16] <h3ll0> pip 7.1.2 from /usr/local/lib/python2.7/dist-packages (python 2.7)

[20:05:16] <h3ll0> ubuntu@ubuntu:~$ pip --version

[20:05:16] <h3ll0> pip 7.1.2 from /usr/local/lib/python2.7/dist-packages (python 2.7)

[20:05:18] <h3ll0> ubuntu@ubuntu:~$ pip3 --version

[20:05:20] <h3ll0> pip 7.1.2 from /usr/local/lib/python2.7/dist-packages (python 2.7)

[20:05:28] <h3ll0> can anyone help with this issue?

[20:06:34] <h3ll0> when doing `sudo pip3 install` or `sudo pip3.4 install` it looks up into python 2.7 dist-packages and asks to update the package instead of installing it for python3