Log file Viewer

[15:21:55] <rzoz> pmxbot, are you from polimetrix? if so, that's a freakish undercurrent from the past.

[15:23:01] <aclark> rzoz: :-)

[15:28:34] <rzoz> quick question: i'm porting an extension library from C to Cython, and while i do this i'm moving from setuptools back to distutils. does the following workflow for unit testing make sense, or is there something obvious i'm missing?

[15:29:02] <rzoz> python setup.py build_ext --inplace; PYTHONPATH=src/ python -m unittest discover tests

[15:30:03] <rzoz> assuming there is a src/ dir with tests/ and another dir containing the module code in it.

[15:30:26] <rzoz> mostly i'm just wondering about whether there's a better way to invoke the unit tests that doesn't require setting PYTHONPATH

[15:33:54] <aclark> rzoz: good q, not sure

[15:34:12] <aclark> J1m might know…

[15:35:56] <rzoz> AFAIK there don't seem to be any automagical additions to PYTHONPATH by distutils. i guess this way works, but it's also not something i saw (quite precisely at least) in the docs, so self.doubt().

[15:35:59] <J1m> Um, buildout and setuptools/distribute make development pretty straightfoward. Buildout sets python path for you.

[15:36:30] <J1m> I don't care to ponder how to make it harder. :)

[15:36:47] <J1m> maybe virtualenv makes it easy too -- not sure.

[15:36:56] <J1m> A key is develop eggs.

[15:37:34] <rzoz> is that the best practice now? last time i was in #python i got screamed at for using setuptools :)

[15:37:57] <J1m> I wonder wtf is going on w distutils2 and packaging. I saw something today about a gsoc project to add develop egg support.

[15:37:59] <rzoz> i prefer it though

[15:38:29] <J1m> setuptools has been very good to me, which isn't to say it isn't flawed.

[15:38:51] <aclark> J1m: basically distutils2 is the name for packaging in py <3.x

[15:38:59] <rzoz> i'm glad to hear that sentiment from another party.

[15:39:09] <J1m> I'm pretty happy with the dev workflow I have now.

[15:39:25] <J1m> Of course, I might be considered biased.

[15:39:52] <J1m> aclark, I have a queezy feeling that distutils2/packaging is uncooked.

[15:40:09] <aclark> J1m: i'm sure it is

[15:40:34] <J1m> Well, it's a fricking long time to provide stop energy.

[15:40:50] <J1m> Very python3nic :)

[15:41:00] <aclark> J1m: i'm using distutils2 trunk to try out pysetup to convert setup.py to setup.cfg, works OK

[15:41:06] <aclark> but that's an edge case

[15:41:08] <aclark> kinda

[15:41:23] <rzoz> J1m: ok -- i think you just talked me back into using setuptools/distribute. thanks

[15:42:14] <J1m> rzoz, imo, people should use setuptools/ until there's a stable alternative with comparable functionality.

[15:42:24] <aclark> rzoz: hell yeah i'd avoid disutils too, it's feature-less

[15:43:36] <J1m> I get the feeling that people close to the Python core don't work on projects for which packaging is relevant. This is frustrating.

[15:44:39] <rzoz> that sounds right. packaging has always been a huge woe for me given existing tools, especially when it comes to dealing with edge cases involving .so files.

[15:45:24] <rzoz> and i was a little shocked when various folks told me to switch back to distutils, but figured i'd give it a shot...

[15:46:21] <J1m> Yeah. C extensions can hurt, especially if they a) depend on other C extensions, or b) depend on external libraries.

[15:46:53] <J1m> We have coping mechanisms that work, but it's still a challenge.

[15:47:44] <rzoz> i'm somewhat permanently stuck in b)-land and there's really no way around requiring $user to build their .so from source, stick it in the LD_LIBRARY_PATH, etc.

[15:49:43] <J1m> sure there is.

[15:50:00] <J1m> There are at least 2 techniques:

[15:51:20] <J1m> 1) Use the zc.recipe.egg:custom recipe, http://pypi.python.org/pypi/zc.recipe.egg/2.0.0a1#creating-eggs-with-extensions-needing-custom-build-settings, together with a automated build of the library, using something like zc.recipe.cmmi, or

[15:53:25] <J1m> 2) If the library is small, include it in the source distribution and do a static build, as was done in zc-zookeeper-static and pyzmq-static

[15:54:27] <rzoz> i think 2 is not an option due to licensing issues, but with 1 could i have it download, run a custom make, then install the resulting .so somewhere that python will see it?

[15:54:54] <rzoz> this is what i'm trying to simplify: http://code.google.com/p/python-zibopt/wiki/Installation

[15:56:36] <J1m> Yes. Use zc.recipe.cmmi (or one of the many variants) to build a buildout-local copy and then use the custom egg recipe (or something similar) to build the extension using the local library. You can use rpath to let the extension know where to find the library at run time.

[15:57:24] <rzoz> J1m: thanks! that'll remove a world of hurt. guess i have some homework now :)

[15:58:28] <J1m> Good luck.

[17:34:32] <aclark> ericholscher: ping

[19:14:15] <MattBowen> Style question

[19:14:28] <MattBowen> how do people here feel about using "or" when setting variables

[19:14:37] <MattBowen> for example: foo = bar or baz

[19:21:58] <benji> MattBowen: I think the "x or y" idiom is just slightly superior to the alternatives.

[19:22:44] <aclark> MattBowen: don't use it myself but don't mind it

[19:31:46] <kennethreitz> MattBowen: it's great

[19:33:50] <aclark> hah

[19:38:17] <rzoz> MattBowen: i think it's quite sensible, often enough

[20:35:06] <dahoste> I like the full ternary operator syntax, if you're using newer versions of python.

[20:35:33] <dahoste> but in its absence, I've been using the hell out of the "x or y" implicit setting behavior.

[20:36:35] <dahoste> I've also broken the habit of writing .keys() for dicts.