Log file Viewer

[00:16:06] <mitsuhiko> dstufft: why in god's name is pyenv incompatible to virtualenv?

[00:17:26] <dstufft> mitsuhiko: incompatible in what way?

[00:17:39] <mitsuhiko> for instance it does not set sys.real_prefix

[00:17:41] <dstufft> I mean I know they are, but I'm not sure which way you're talking about

[00:17:43] <dstufft> ah yea

[00:17:48] <dstufft> real_prefix vs base_prefix is kinda crappy

[00:17:59] <dstufft> a future virtualenv is going to set both real_prefix and base_prefix :/

[00:18:18] <mitsuhiko> why ...

[00:20:54] <mitsuhiko> dstufft: does virtualenv use pyenv machinery if available or are they separate?

[00:23:30] <dstufft> mitsuhiko: currently they are seperate, my plan is for in the future virtualenv will use the pyenv machinery if they are available, and then it'll use it's own machinery if not, and ontop of the actual isolation machinery it'll unify the API between them

[03:02:10] <Phagus> Okay, I'm trying to get Kivy to work within a virtualenv. I'm working on Arch Linux. There's an AUR entry for Kivy that works, but I want to use it in a Python2 virtualenv

[03:02:45] <Phagus> When I run `pip install kivy` within the virtualenv, it throws horrible exceptions

[03:03:03] <Phagus> I have cython and other Kivy dependencies installed within the virtualenv

[03:03:15] <Phagus> I'm also using virtualenvwrapper

[03:04:33] <Phagus> How can I use the AUR Kivy in my virtualenv?

[05:49:47] <ionelmc> Phagus: have you tried the --system-site-packages option?

[08:28:32] <Phagus> ionelmc: What's that?

[08:36:48] <ionelmc> Phagus: it lets your virtualenv see the global packages

[13:33:03] <dstufft> mitsuhiko: ping

[13:33:09] <mitsuhiko> dstufft: pong

[13:34:42] <dstufft> mitsuhiko: is there an easy way to test a click @command.group() function? I can't seem to figure out how to actually execute one, calling a subcommand via CliRunner().invoke() doesn't seem to execute the group command, nor does calling the group command via CliRunner().invoke(), and calling it directly wants to act like I'm calling it via the CLI

[13:35:20] <mitsuhiko> i'm a bit confused now :)

[13:35:33] <dstufft> I have https://bpaste.net/show/a59dec31182e and I want to test the bits inside the function call

[13:35:34] <mitsuhiko> are you saying that CliRunner does not behave like the cmdline?

[13:36:14] <dstufft> mitsuhiko: yea, executing a subcommand of that does not execute that function

[13:36:44] <mitsuhiko> that ... should not happen

[13:36:50] <dstufft> I had to pass in an obj onto the context via CliRunner().invoke(obj=foo)

[13:36:56] <mitsuhiko> actually, maybe

[13:36:59] <mitsuhiko> dstufft: which version of click do you have?

[13:37:11] <dstufft> 3.3

[13:38:40] <mitsuhiko> dstufft: out of curiosity: which version of python?

[13:38:47] <dstufft> 3.4

[13:38:57] <dstufft> 3.4.2 to be exact

[13:41:56] <mitsuhiko> hmm. cannot reproduce

[13:42:12] <mitsuhiko> https://gist.github.com/mitsuhiko/c021fe4af465168b6035

[13:42:14] <mitsuhiko> is that what you do?

[13:45:17] <dstufft> oh, maybe I'm using it wrong

[13:45:20] <dstufft> here's what I have

[13:45:30] <dstufft> https://bpaste.net/show/1ff2563e3a10

[13:45:42] <dstufft> it doesn't fail until line 22 (called like python test.py foo)

[13:45:43] <mitsuhiko> dstufft: yeah, foo does not know anything about its parent

[13:45:55] <mitsuhiko> you can link them to independent parents if you want

[13:46:11] <dstufft> ah

[13:46:14] <dstufft> so I'm just doing it wrong, ok!

[13:46:16] <mitsuhiko> eg: a command "foo" can exist twice, once below "x1" and once below "x2" for instance

[13:46:23] <mitsuhiko> dstufft: there are different things you can do however

[13:46:41] <mitsuhiko> if you want to test them in isolation you can have different ways to setup the context object (eg: pass it in preconfigured)

[13:47:10] <mitsuhiko> it's actually also quite possible to make the commands work completely in isolation of their parents with a bit of trickery

[13:47:30] <mitsuhiko> for instance i use make_pass_decorator with the ensure flag to lazily construct a custom context object

[13:47:40] <mitsuhiko> so each command as it passes execution downwards can modify the state of it

[13:47:59] <dstufft> yea I'm passing it in preconfigured right now in the subcommands, because they only rely on the group in order to setup an object, and I can just do CliRunner.invoke(..., obj=<preconfigured>)

[13:48:33] <mitsuhiko> http://click.pocoo.org/3/complex/#interleaved-commands

[13:48:40] <mitsuhiko> that plus next section

[13:49:23] <mitsuhiko> i pretty much only write click apps with make_pass_decorator now instead of manually maintaining ctx.obj

[13:50:47] <dstufft> cool

[13:50:47] <mitsuhiko> dstufft: https://gist.github.com/mitsuhiko/830d6d557c3ad89e8e72

[13:50:48] <dstufft> thanks

[14:17:26] <mathieui> Hi, I come to report on https://bitbucket.org/pypa/setuptools/issue/137/typeerror-unorderable-types-str-nonetype (or https://github.com/pypa/pip/issues/2357 or https://github.com/pypa/pip/issues/2353)

[14:17:53] <mathieui> I’ve reached the conclusion that it only appears on debian and derivatives, from my tests

[14:24:01] <mgedmin> https://bitbucket.org/pypa/setuptools/issue/137/typeerror-unorderable-types-str-nonetype#comment-14645245 mentions centos

[14:27:02] <mathieui> for the record, I have an install script that creates (or upgrades) a venv, activates it, and then tries to install/upgrade dependencies for the current project; weirdly, the issue only appears the third time I run that script

[15:05:42] <mathieui> found what triggered it: installing the original stuff through the systems setuptools, and then having setuptools as a dependency, which would make it install the (way) more recent version from pypi

[15:06:18] <mathieui> and then somehow a subtle incompatibility exists, which causes the relevant traceback

[15:06:57] <mathieui> (that also explains why gentoo or archlinux aren’t hit, as the packaged setuptools is closer to upstream)

[16:17:44] <ionelmc> mathieui: it's caused by haveing multiple versions of the same package installed

[16:18:09] <ionelmc> and those versions have different install flags (whatever that is) - thus the compare error

[16:40:24] <can-of-bees> hi all. i'm trying to `pip install hgview` but getting an asciidoc error (it isn't installed). when i try to install asciidoc, pip can't find any downloads.

[16:40:58] <can-of-bees> is this a case where i should grab the source from the asciidoc homepage and build it?

[16:42:09] <apollo13> asciidoc doesn't seem to be on pypi, so…

[16:42:43] <apollo13> can-of-bees: you need to install it via your system package manager I'd say

[16:44:38] <can-of-bees> apollo13: thanks!

[16:45:07] <can-of-bees> apollo13: i wasn't sure -- thought it was odd that it comes back in pip search and wanted to be sure i wasn't missing something. cheers!

[20:11:59] <_habnabit> what would it mean if pip is failing with 'Directory not empty: /path/to/virtualenv/build' ? it's happening on cleanup after pip says all of the dependencies successfully built. the build directory contains a bunch of non-empty subdirectories

[20:12:20] <_habnabit> i've never seen this failure before

[20:13:50] <_habnabit> python 2.7 on ubuntu 14.04; trying to figure out what version of pip it is

[20:14:11] <_habnabit> pip 1.5.4

[20:17:29] <tomprince> I know the build directory stuff has changed signifigantly since them. I don't know the details. (It uses randomized build directories, rather than a fixed name, most of the time, for example.

[20:18:06] <_habnabit> i'll see if it's fixed in newer versions of pip

[20:36:09] <_habnabit> tomprince, haha, it's fine in newest pip

[20:36:12] <_habnabit> that's hilarious

[21:49:21] <ionelmc> mgedmin: pon

[21:49:23] <ionelmc> pong

[23:00:20] <_habnabit> so i just set a version to '1.0+internal-1' in the setup.py and pip is installing it as '0.1-internal-1'. is this intentional?

[23:01:38] <_habnabit> i get the same behavior if i just `python setup.py install` too

[23:04:05] <tomprince> New pip will install as 1.0+internal.1

[23:04:26] <tomprince> The version you are using is pre PEP440, which normalizes + to -.

[23:04:27] <_habnabit> tomprince, an as-yet-unreleased pip?

[23:04:54] <tomprince> 6.x should do the right thing. (Or maybe it is setuptools that is doing that)

[23:05:09] <tomprince> I think setuptools 8 introducted PEP440 support.

[23:05:16] <_habnabit> i'd think it's setuptools doing that, if not involving pip at all has the same problem

[23:05:51] <_habnabit> the package does `from setuptools import setup`

[23:05:57] <tomprince> So, not intentional.

[23:06:18] <_habnabit> ah, this is setuptools 7.0

[23:06:20] <_habnabit> i'll try upgrading

[23:07:28] <_habnabit> okay, using latest setuptools and pip is installing it as 1.0+internal.1

[23:08:12] <tomprince> https://www.python.org/dev/peps/pep-0440/#local-version-segments is why - -> .

[23:08:25] <_habnabit> yeah i've been reading that