Log file Viewer

[00:03:39] <ToBeReplaced> carljm: yeah, that's what i meant, thanks

[00:31:40] <gnis> I'm trying to install packages with "pip install -r requirements.txt" command, and I'm getting an IMPORT error b/c for some reason a package that comes AFTER NumPy cannot import NumPy...

[00:32:01] <gnis> Is there a way to apply the package to pip as you install recursively?

[06:25:07] <mgedmin> wheee, 503 errors hello again

[08:28:18] <NeverW8> Aloha people, if I have the pip and setup.py etc etc and want to install it in a directory and not system wide, is there somehow I can define that? I dont want to use virtualenv :) thanks

[08:28:42] <NeverW8> More or less, I only want it for one user

[08:29:10] <ronny> NeverW8: there is pip install --user which install s something to user-site

[08:30:21] <NeverW8> Maybe I formulated my question wrongly, I dont have pip install yet, can I do something like ./setup.py --user ?

[08:30:49] <ronny> NeverW8: what system are you using?

[08:30:55] <NeverW8> RHEL6

[08:31:40] <ronny> ouch

[08:31:51] <ronny> NeverW8: and what do you want to use pip for on that box?

[08:32:12] <ronny> (usually those legacy enterprise distros put one in quite some pain)

[08:32:37] <NeverW8> I need it to run some things, but cant install it system-wide, since it's a quite big enviroment :P

[08:32:58] <NeverW8> Production enviroment should be noted

[08:33:28] <NeverW8> I would like to skipp re-write the whole python install file

[08:34:18] <ronny> NeverW8: for deployment on enterprise distros i usually set up a virtualenv by downloading latest virtualenv, and then running it and afterwards installing the things in the virtualenv

[08:34:28] <mgedmin> I'm sure there is some way to have pip/setuptools install somewhere with a prefix, since I heard fedora does that as part of their rpm packaging

[08:34:37] <mgedmin> personally I'd say virtualenv would be less painful

[08:34:41] <ronny> NeverW8: making a virtualenv and then putting recent things in there is probably your best bet

[08:35:04] <NeverW8> Hmm, I could maybe do something tricky then define it in the users bin file.. hmm

[08:35:05] <mgedmin> pip install has a --target <dir> option (that I've never used)

[08:35:08] <ronny> NeverW8: btw, what software do youactually want to install

[08:35:10] <NeverW8> I think so to ronny

[08:35:25] <NeverW8> I already fetched the libs I want to use :)

[08:35:36] <mgedmin> also pip install --root <dir>

[08:36:23] <ronny> mgedmin: please dont suggest random options to someone not well-versed with the tool yet, it may casue more pain later on

[08:36:34] <NeverW8> Ohh, I could install it in my sandbox env then clone it and change the systempaths, if it works

[08:36:44] <NeverW8> I will try, thanks anyways people :)

[12:31:23] <d0ugal> Do wheels include all the package dependencies too? That sounds wrong to me, but I don't know much about wheels specifically.

[12:32:29] <ronny> d0ugal: wheels contain metadata about what dependencies are required, pip uses that to download those as well

[12:33:08] <d0ugal> ronny: cool, that makes sense and what I expected. Somebody just said the opposite to me :)

[12:33:11] <d0ugal> Thanks!

[12:34:14] <ronny> d0ugal: it would b possible to abuse the wheel format and include dependencies, but thats not officially supported by the specification and default tools

[12:34:34] <ronny> d0ugal: there is a different pep about putting a application and its dependencies into a zipfile

[12:35:43] <d0ugal> ronny: Gotcha, I don't want to do that :) I was trying to understand the benifits of using wheels in a pure python lib. It seems the key one is the removal of executing setup.py code on the installing machine.

[12:36:58] <ronny> d0ugal: installation of a pure python wheel is basically unizp:copile all py files to pyc; create scripts

[12:37:12] <d0ugal> Neat

[12:37:36] <d0ugal> I'm about to finally start shipping wheels, just trying to catch up first :)

[12:37:51] <ronny> d0ugal: the fun detail, binary wheels are installed in the same way

[12:38:00] <d0ugal> ha, that's cool

[12:38:01] <ronny> so its a great way to support windows users

[12:38:19] <ronny> but unfortunately binary compatibility problems make it a bad choice for linux

[12:38:44] <ronny> however one should still support them, in future pip will cache wheels for all sdists where it can make wheels

[12:39:42] <xafer> d0ugal, for pure python libs, you typically see a 2x speedup in installation time with wheels compared to a sdist

[12:40:18] <d0ugal> ronny: Yeah, I can't wait for the wheel cache, that is going to be epic :)

[12:40:25] <d0ugal> xafer: Nice, that's an added bonus

[18:14:04] <ronny> dstufft: is there any way fr a wheel to say its not compatible to certain python vversions (i want to make wheels that are 3.3+ and 2.7)

[18:17:50] <dstufft> ronny: not really, the wheel filenames are't designed to show compatability exactly, more like "if I run the setup.py bdist_wheel on Python 3.2 and Python 3.3 will I get the same output?"

[18:19:06] <ronny> dstufft: thing is, the code i make wont work or be tested on 3.x < 3.3

[18:20:20] <dstufft> ronny: doesn't matter, the wheel filename isn't a compatibllity thing, it's a "will I get the same output". PEP 426 I think has the ability to explicitly mnetion what versions of Python your project supports (and thus bomb out if you try and install)

[18:27:24] <ronny> dstufft: so fro wheels i shoudlnt even try?

[18:27:49] <ronny> dstufft: i suppose adding python version tags like py27.py33.py34.py35 should be fine?

[18:28:00] <dstufft> ronny: yea it should work

[18:28:40] <ronny> dstufft: i want to go for explicirly stating python minor version supported anyway ^^ (at least atm)