Log file Viewer

[16:10:32] <Ivoz> dstufft, 'nother nag for virtualenv

[16:10:59] <Ivoz> or qwcode you interested? want to put out release

[16:13:25] <qwcode> Ivoz, I let dstufft do that : ) usually we do pip and virtualenv at the same time... you want to do it separate?

[16:13:57] <Ivoz> qwcode, ya... it's broken for python 3.5

[16:14:24] <Ivoz> Current develop will fix non-windows-3.5

[16:15:06] <Ivoz> I've been working on trying to fix as many small niggles as possible people have had

[16:15:22] <qwcode> Ivoz, roger, how about send out email to pypa-dev and state the case

[16:15:46] <Ivoz> while the rewrite branch makes its merry way towards stable

[16:16:55] <Ivoz> Also wondering about our status with gpg-signing things....

[16:17:14] <Ivoz> ATM is the bus factor 1 for that, for each project?

[16:17:30] <qwcode> Ivo, yea, I was thinking about that.

[16:18:06] <Ivoz> Surely if we want it more than just "oh look a pgp signature" we'd want to get a PyPA signing key

[16:18:20] <Ivoz> to then trust one or two pypa devs for each project

[16:20:01] <Ivoz> Is there some sort of framework for keys saying they trust other keys to make releases for X project(s)?

[16:21:17] <Ivoz> haha sure enough donald wrote a blog on this... /reads

[16:36:52] <Ivoz> I also noticed we don't have any packaging history for 2015 :D https://www.pypa.io/en/latest/history/

[16:36:56] <Ivoz> Surely we've done some stuff this year

[16:44:00] <Ivoz> Hmm, I think the best point we could get involved package signing was at least saying "This person created X project"

[16:45:41] <Ivoz> or, in a more complicated case, X key is trusted for B package, and X key trusts Y and Z keys to release packages for B, and this release of the package was signed by Z, so it should be trustworthy"

[18:17:05] <Ivoz> qwcode, was thinking about asking for that to go in develop instead

[18:17:29] <qwcode> Ivoz, yea, I didn't notice : (

[18:17:55] <Ivoz> If you merge master into develop now, will git complain about anything in the future?

[18:18:29] <Ivoz> Like when we pull back develop into master to cut a new release

[18:21:39] <qwcode> it probably be ok, would have to look at the merge, but I'd prefer on principle not to do it in reverse like that.... shrug

[18:24:01] <Ivo> boop

[18:24:13] <Ivo> yay accidentally running two irc clients

[20:28:10] <chogan> Hi. I'm trying to build setuptools with a python I built with the Intel compiler on OS X by running python bootstrap.py, but for some reason it's unable to import setuptools.command in setuptools/command/__init__.py. Any advice?

[20:29:50] <chogan> Here's the full stack trace: Regenerating egg_info

[20:29:50] <chogan> Traceback (most recent call last):

[20:29:50] <chogan> File "bootstrap.py", line 57, in <module>

[20:29:50] <chogan> run_egg_info()

[20:29:50] <chogan> File "bootstrap.py", line 50, in run_egg_info

[20:29:50] <chogan> subprocess.check_call(cmd)

[20:29:51] <chogan> File "/nfs/site/home/chogan/mac_build/lib/python2.7/subprocess.py", line 540,

[20:29:51] <chogan> in check_call

[20:29:51] <chogan> raise CalledProcessError(retcode, cmd)

[20:29:52] <chogan> subprocess.CalledProcessError: Command '['/nfs/site/home/chogan/mac_build/bin/py

[20:29:52] <chogan> thon2.7', 'setup.py', 'egg_info']' returned non-zero exit status -11

[20:31:59] <Ivo> chogan, why not use ez_setup.py

[20:33:09] <Ivo> chogan, or you could try get-pip.py as well

[20:33:19] <Ivo> which might be able to give you both pip & setuptools for free

[20:35:43] <chogan> Ivo: We are creating a distribution for python so we don't want to download packages during the build process

[20:36:19] <Ivo> chogan, also, why not 3.x? Don't stay in the past :(

[20:36:35] <chogan> Ivo: We're distributing 2.7.10 and 3.5

[20:37:08] <chogan> The bootstrap.py method above worked on linux, but I'm having trouble with OS X

[20:37:44] <Ivo> chogan, what error do you get just running python setup.py egg_info

[20:38:13] <chogan> Ivo: Segmentation fault 11

[20:38:28] <Ivo> so same error

[20:38:31] <Ivo> hopefully in same place

[20:38:44] <chogan> Yeah, I tracked it to that import statement with the debugger

[20:39:48] <Ivo> chogan, if you don't care about how "pure" your bootstrap is, you can also use a zip of pip to install a setuptools wheel

[20:40:00] <qwcode> chogan, Ivo, see here https://pip.pypa.io/en/stable/installing/#install-pip one of the examples explains using options with get-pip.py to install from local distributions

[20:42:03] <Ivo> chogan, get-pip.py, at it's barest mechanics, is just doing python -m <pip.whl renamed to be a zip> install <pip.whl> <setuptools.whl>

[20:42:51] <Ivo> chogan, also, have you tried python -m ensurepip ??

[20:43:25] <chogan> Ivo: That gives the same segmentation fault.

[20:43:47] <Ivo> chogan, which, -m ensurepip?

[20:43:52] <chogan> Yes

[20:44:22] <Ivo> Well that's a difference between your compiled python and a gcc compiled python...

[20:44:37] <Ivo> gonna take some debugging I guess

[20:44:43] <chogan> Ivo: that's what I was afraid of.

[20:44:54] <chogan> Ivo: thanks for your help

[20:45:21] <Ivo> https://docs.python.org/2.7/library/ensurepip.html is designed to put pip & setuptools in your python env without even net connection

[20:46:00] <Ivo> same is present in 3.4+

[20:46:38] <chogan> Ivo: Interesting

[20:47:09] <chogan> Ivo: Aren't they pre-packaged in > 3.3, or do you still have to run ensurepip?

[20:47:48] <Ivo> IIRC, in a vanilla python dist tar, yes it will already come with it

[20:48:00] <Ivo> Some linux distros didn't like that...

[20:48:38] <dstufft> you have to run ensurepip, but the Makefile in 3.4+ will run it by default (as does the windows/osx installers)

[20:48:48] <dstufft> in 2.7.9+ the installers run it by default, but the Makefile does not.

[20:49:24] <Ivo> I'm guessing there's a half decent chance something could be really bugged with the compilation if it's givng you a segfault

[20:50:16] <chogan> Ivo: Yeah, I'm getting 12 segfaults when running the cpython regression tests too. I need to look at compilation again.

[21:54:39] <xafer> https://github.com/pypa/pip/pull/3153 should be ready for review/merge :)