Log file Viewer

[00:10:21] <elestud> hello -- does anyone know the recommended procedure for using pip to install modules that require the python development headers? I have Python installed on the system from source, but since pip installs it's own version, it won't read them

[00:11:33] <elestud> ack sorry -- pip under virtualenv, rather

[01:05:14] <tdsmith> elestud: of what does pip install its own version?

[01:05:18] <tdsmith> it should just work

[01:05:47] <elestud> I understand what's happening now, but I'm not sure how to fix it

[01:06:11] <elestud> I installed a new version of python on my system (2.7.9). The system default was 2.7.5

[01:06:31] <elestud> Then I used that newer version of python to install setuptools, and used setuptools easy_install to install pip

[01:07:00] <elestud> I used pip to install virtualenv.. but for some reason, when I create a virtualenv it uses python 2.7.5 instead

[01:07:59] <tdsmith> i'm guessing head -1 `which virtualenv` points to the wrong python

[01:08:43] <tdsmith> you can always pass -p to virtualenv to tell it to use a different interpreter

[01:09:12] <elestud> ahh, you're correct

[01:09:27] <tdsmith> the shebangs that distutils and/or pip write point to the interpreter which was used to install the package

[01:10:12] <tdsmith> i'm guessing one of the commands you ran actually 'belonged' to the system python

[01:10:13] <tdsmith> you can always invoke pip like `/path/to/python -m pip install my_package` to be very specific about which interpreter should do the installing

[01:10:27] <elestud> so I'm trying to figure out which command that would have been

[01:10:36] <elestud> setuptools was installed with the new interpreter

[01:10:48] <elestud> and pip was installed with setuptools easy_install command

[01:11:05] <elestud> maybe easy_install defaults to the system version of python?

[01:12:34] <tdsmith> you can look at its shebang the same way we looked at virtualenv

[01:12:42] <elestud> ok, the easy_install shebang is correct

[01:12:55] <elestud> will check pip next

[01:14:25] <tdsmith> if you find yourself doing this in the future, you can download and execute https://bootstrap.pypa.io/get-pip.py to get pip and setuptools in one fell swoop. if you're building 2.7.9+, you can also run python -m ensurepip

[01:15:51] <elestud> ok, I've gone over everything again -- and the shebangs for easy_install and pip point to the old version of python

[01:16:07] <elestud> I'm trying to figure out how that's possible though, since I installed setuptools with the newer interpreter

[01:16:41] <tdsmith> maybe a PATH priority issue?

[01:17:05] <elestud> the path to the bin directory with the new Python is the first item in the PATH

[01:17:24] <elestud> /usr/local/bin

[01:18:33] <elestud> and running python2.7 --version yields Python 2.7.9 as expected

[01:19:44] <elestud> thanks for your help, btw

[01:21:04] <tdsmith> oh, you're welcome

[01:21:12] <tdsmith> dunno what happened then; how'd you install setuptools?

[01:22:33] <elestud> I installed setuptools from source, using the newer version of python to run setup.py install

[01:35:10] <tdsmith> if you just ran "python" maybe your shell didn't realize you had a new python earlier in the path and needed to be rehashed? ¯\_(ツ)_/¯ dunno, sorry

[01:53:44] <elestud> tdsmith: I'm retracing the install steps in a new VM now to try to discern where things went wrong

[02:03:00] <elestud> ok, I found it

[12:56:28] <nedbat> requires.io will look for req*.txt files, or req*.pip files. I like the .pip extension, since these aren't actually text in the first place. Is there a reason (other than unfamiliarity) to not call my file requirements.pip ?

[13:11:08] <doismellburning> nedbat: oooh cute

[13:13:02] <nedbat> doismellburning: ikr?

[13:39:15] <dstufft> nedbat: inertia?

[13:40:37] <nedbat> dstufft: screw that: https://bitbucket.org/ned/coveragepy/commits/58ca9fc280aec6a1ed8e68fcb9be50daef4321b7

[13:41:19] <dstufft> you probably don't need it in your MANIFEST.in

[13:41:33] <nedbat> dstufft: yeah, I know, I wondered about why that line was in there in the first place....

[13:41:57] <dstufft> (it's me, I'm the one who makes an unrelated point about a stupid packaging file)

[13:42:23] <dstufft> nedbat: I think the pip documentation uses "requirements.txt" which is probably where that name comes from

[13:42:31] <nedbat> dstufft: yup

[13:43:31] <dstufft> I don't think we'll be rid of "requirements.txt" though

[13:43:39] <dstufft> that name is baked into a lot of things now

[13:44:03] <dstufft> e.g. https://github.com/heroku/heroku-buildpack-python/blob/master/bin/detect#L18

[13:45:33] <dstufft> someday I want to write a "Requirements 2.0" format that is nicer to use and uses a better name too

[13:46:50] <nedbat> dstufft: yeah, i was just dealing with a backwards breakage because i changed an internal filename in coverage.py

[13:47:28] <dstufft> nedbat: woo working on important tooling to the ecosystem where suddenly everything becomes a public api

[13:47:54] <dstufft> https://xkcd.com/1172/ every day

[13:48:13] <nedbat> dstufft: this was a really weird one too, i can't fathom the developer's mindset that came up with the logic they were using.

[13:48:56] <nedbat> dstufft: that's a good xkcd that was not in my lru cache :)

[13:50:17] <dstufft> nedbat: I expect much wailing and gnashing of teeth when Warehouse goes live from people who are depending on the craziest things

[13:50:25] <nedbat> omg, yes

[13:50:45] <dstufft> I'm going to hide for a month after it does