Log file Viewer

[06:53:26] <adamg> so FYI, I think there's going to be a lot of breakage from people who do pip install --upgrade setuptools and/or pip with the 19.4 and 8.0 releases. I just hit https://bitbucket.org/pypa/setuptools/issues/485/differences-setuptools-193-and-194-loading and https://bugs.launchpad.net/openstack-ansible/+bug/1535998 with reqs files that worked fine with 7.1.2 and 19.3

[06:54:06] <adamg> I'm on ubuntu 14.04 (the most recent LTS...), pretty sure it's going to impact debian jessie too

[07:34:38] <goodwill> question about: https://github.com/pypa/pip/issues/1274

[07:34:49] <goodwill> is there anyway to force this to be disabled always

[07:35:12] <goodwill> I mean it's like a major security issue to have pip wander around the internet installing from random places

[07:39:51] <tdsmith> i don't understand the security issue wrt requirements.txt

[07:46:53] <tdsmith> pypi isn't an audited repository; it is perhaps not that morally different from installing a package from v1agra4u.ru

[08:10:55] <adamg> yup. IRL, on systems where it matters, it's "disabled always" by not allowing pip/the system access to random places on the WAN (which definitely includes pypi), period. code only ever gets installed from packages that are made available to it via a secure channel. (...in theory anyway)

[09:57:32] <linovia> Is there a way to request virtualenv to install pip but avoid upgrades ? The travis / tox build should be using travis 6.x pip but in the virtualenv it ends with 8.0 which doesn't work with the py32 builds

[09:57:55] <linovia> and the --no-pip simply doesn't install pip at all

[09:58:24] <mgedmin> how badly do you need to support py32?

[09:59:45] <linovia> mgedmin: well, no idea, it's on django-rest-framework

[10:02:08] <linovia> I don't think it's a good idea for DRF to drop the 3.2 support from one day to another.

[10:28:07] <linovia> ok, downgrading virtualenv to < 14 was enough to fix the builds. We'll remove 3.2 in the next minor but meanwhile we'll still have the builds

[10:28:21] <linovia> thanks to all and cheers for pip 8 !

[11:17:31] <dstufft> linovia: virtualenv 14.0 has pip 8 bundled inside of it (and uses the bundled pip 8 to install pip)

[11:17:40] <dstufft> so your only hope for 3.2 is older virtualenvs

[11:33:20] <[Tritium]> what isnt in python 3.2 that called for pip dropping support for it?

[11:34:02] <ronny> [Tritium]: its eol since a while now

[11:34:29] <ronny> plus u'' strings for a vendored package

[11:35:21] <[Tritium]> ok. Thats a real answer. "Python 3.2 isnt supported, so we intentionally break for no reason" is what I was hoping NOT to hear

[11:36:09] <dstufft> Every version of Python we support adds overhead, both for ourselves and for our dependencies who are gracious enough to continue supporting it even when they no longer want to because pip supports it

[11:37:23] <[Tritium]> dstufft: I understand that. The only thing that would irk me is if there was no additional support burden, and a version check was added. ... i have run into that

[11:38:14] <ronny> [Tritium]: at least one vendored library uses unicode literals now, that was added in 3.3

[11:38:35] <[Tritium]> ronny: i...understand that.

[11:38:40] <dstufft> (it always used unicode literals and I manually patched it not to use that)

[11:38:51] <ronny> oh, i see

[11:39:01] <ronny> so the situation was even worse

[11:39:26] <[Tritium]> having to vendor code is a poor situation to begin with

[11:40:05] <ronny> a non-vendored solution is impossible due to major strucutral issues in the python import system

[11:40:56] <[Tritium]> not to mention that it is unreasonable to expect the package manager to depend on packages before the package manager is installed

[11:41:49] <dstufft> [Tritium]: but yea, this is almost entirely about freeing up our dependencies to drop support for 3.2 and enabling us to stop testing against 3.2, there wasn't a major show stopping feature that prevented us from supporting 3.2, just it's usage numbers dropped, it's EOL within a month from now so dropping it makes things a bit easier. In your case, it shouldn't (hopefully?) be super hard to just continue to use pip <8 and virtualenv <14

[11:41:51] <ronny> its reasonably simple to make a zipped executable that includes the wheels in some way to make a installer, also get-pip can just load wheels

[11:42:15] <dstufft> -> Takes Alyssa to the bus stop

[11:42:50] <[Tritium]> dstufft: I will just avoid upgrading a server that is going to get replaced once ubuntu 16.04 drops

[11:45:36] <linovia> dstufft: we'll drop 3.2 in the next minor release. I was a bit surprised at first but that's all for the best so it's fine seing packaging moving forward <3

[11:46:13] <ronny> dstufft: btw, is there a reasonable way to make wheels for just the supported python versions?

[11:47:08] <ronny> (i would suppose blindly setting a version tag in setup.cfg is prime matter for breaking pip wheel caching)?

[11:54:12] <dstufft> ronny: if you build a py33 wheel it'll be used for 3.3+

[11:54:40] <dstufft> linovia: time moves in one direction, forward!

[11:54:54] <ronny> dstufft: so if the wheel is py27.py33, it will be used on python 3.4 and 3.5 as well?

[11:55:09] <dstufft> ronny: you'll want to test that to verify it, but yes I believe so

[12:00:29] <ronny> k

[13:15:01] <wiggy> is it a known issue that pip 8 breaks when you insatll a package in a virtualenv, and it tries to uninstall a system package as part of that?

[13:20:27] <ronny> wiggy: i dont thik so, more context please?

[13:22:26] <dstufft> wiggy: https://github.com/pypa/pip/issues/3384

[13:24:35] <wiggy> dstufft: we hit that exact argparse issue, only with requests

[17:03:41] <tdsmith> dstufft: thanks for that pip change! Did get-pip ever install eggs?

[17:03:54] <dstufft> *ever*?

[17:03:56] <dstufft> um

[17:03:58] <dstufft> maybe?

[17:04:02] <dstufft> I don't recall

[17:04:10] <tdsmith> i kind of imagined the problem was that travis easy_installed things into their image

[17:06:28] <tdsmith> i was a little surprised to see a change to pip

[17:13:32] <dstufft> tdsmith: for the Extras thing?

[17:15:15] <tdsmith> dstufft: this comment: https://github.com/Homebrew/homebrew-python/issues/274#issuecomment-173171448

[17:16:18] <dstufft> tdsmith: Oh, I think I Got confused

[17:16:26] <dstufft> I thought this was the Extras problem again for some erason

[17:17:50] <dstufft> basically that comment is entirely unrelated and I should probably do less things at 6am

[17:23:29] <tdsmith> phew :)

[17:46:57] <natefoo> ooh, pip 8

[18:07:46] <ngoldbaum> not to be confused with pep8 of course ;)

[18:21:06] <nanonyme> Maybe you should have skipped 8 and went straight to 11 :)

[20:40:39] <arooni> hey folks; i have pip installed through brew on os x when i run pip install power line .. i see "Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/tp/49m9s7hx6895880pp1vjr0_m0000gn/T/pip-build-1IEhCp/powerline"

[20:43:34] <tdsmith> you probably mean powerline-status

[20:45:02] <mcepl> hi, guys ... trying to change setup.py for M2Crypto so that build command would have option --openssl which would (if set) set --openssl option for build_ext. Is it possible? What I have now is http://paste.fedoraproject.org/312974/22177145/ but I don't have to access the other command options.

[20:46:14] <tdsmith> idk but as an aside if you can use pyca/cryptography instead of m2crypto you will probably be much happier

[20:46:49] <mcepl> tdsmith: I am a maintainer of M2Crypto ... ;)

[20:47:07] <tdsmith> doubly true, then :p

[20:47:14] <tdsmith> sorry if i gave offense

[20:48:25] <mcepl> tdsmith: no offense taken ... the point is to keep for legacy users, I didn't how incredible number project still uses it.

[20:48:38] <mcepl> I know pyca is probably better, but that isn't the point

[20:48:58] <mcepl> just as a way of advertisement https://gitlab.com/m2crypto/m2crypto/ ;)

[20:49:37] <dstufft> M2Crypto is being maintained again?

[20:49:45] <mcepl> yes

[20:49:49] <dstufft> that's great

[20:50:03] <mcepl> tdsmith: you see? ;)

[20:50:54] <tdsmith> it's been frustrating packaging m2crypto for homebrew so i'm glad it's back in good hands

[20:53:28] <mcepl> tdsmith: well ... Mac is kind of problem ... https://gitlab.com/m2crypto/m2crypto/issues/72 and https://gitlab.com/m2crypto/m2crypto/issues/63 ... merge requests are very very welcome, I don't know anything about Mac.

[20:54:19] <mcepl> (working for Red Hat, no, it is not part of my job description yet, I have no access to Mac at all).

[20:54:57] <ngoldbaum> mcepl: ugh, i also recently had to deal with apple getting rid of the SSL headers in 10.11

[20:56:37] <mcepl> ngoldbaum: I think the current state of our understanding is that we gave up on the system OpenSSL at all, and we will probably require on Mac OpenSSL from brew

[20:57:26] <mcepl> but as I said, if somebody who actually knows something about Mac would chime in, I am all ears.

[20:58:54] <mcepl> which leads me back to https://gitlab.com/m2crypto/m2crypto/issues/89 which I am trying to solve and pushing setting from build option to build_ext.

[21:54:15] <mcepl> all: could I get some comments on https://gitlab.com/mcepl/m2crypto/commit/af47a5d0a996c6fd86f0db1dd954777d72d2fc8a please? Is there some better construct?

[22:19:21] <mcepl> it's https://gitlab.com/m2crypto/m2crypto/merge_requests/45 now. Comments welcome!

[23:21:52] <wsanchez> mcepl: There is no system OpenSSL on Mac OS. There is a private dylib, but unless you are Apple, it's best to consider that non-existent.

[23:22:36] <wsanchez> If you need OpenSSL, built it. Or brew/ports/whatever you prefer.

[23:34:13] <mcepl> wsanchez: but there is that crazy openssl-0.9.8z* stuff, isn't there?

[23:44:22] <rZ_> question wrt pip: is it safe to assume that any platform tag starting with macosx is *not* on mac os 9 or lower? https://github.com/pypa/pip/blob/develop/pip/pep425tags.py#L172,L188

[23:46:48] <tdsmith> mcepl: not anymore; in any case it's better not to use it