Log file Viewer

[16:37:14] <rnix> hi, i cythonized some modules of a python package and tried to create an egg with python setup.py bdist_egg --exclude-source-files. The contained *.so files are included, but also the compiled pyc files are and the 'so' files never are used.

[16:37:59] <rnix> is setuptools not able to correctly build eggs with cythonized files or might this be an error when cythonize files with py extension instead of pyx?

[16:46:43] <ronny> rnix: setuptools is reassonably unaware of cython, you could exclude those files

[16:47:20] <rnix> well after cythoning the modules are just shared objects.

[16:48:06] <rnix> and the source code of setuptools semm to be aware of shared objects - https://bitbucket.org/pypa/setuptools/src/acb8319982f13971962e94d77a71c79befce87c4/setuptools/command/bdist_egg.py?at=default#cl-326

[16:48:57] <rnix> so there might be a problem when building so files from py files instead of pyx files

[16:49:32] <rnix> the thing is that installing from sdist works

[16:55:32] <ronny> rnix: did you exclude them from find_packages?

[17:00:52] <rnix> no

[18:26:59] <rnix> back from phone. i also tried with the excludes now. all this has no effect when building with bdist_egg --exclude-source-files

[18:45:05] <ronny> i see

[18:45:12] <ronny> rnix: btw, wh do you distribute eggs?

[18:46:42] <rnix> still with py27 for lots of stuff

[18:47:15] <ronny> rnix: thats unrelated ^^

[18:47:30] <rnix> maybe by habit if the question is why i don't use wheel

[18:50:19] <rnix> ronny: or what else do you mean?

[18:51:48] <ronny> rnix: wheels work for python 2.x as well

[18:52:03] <ronny> egg is the setuptools only format that pip will never handle

[18:53:43] <rnix> and it's actually b/c?

[18:56:22] <rnix> probably i need to take a look at wheels

[18:57:26] <ronny> rnix: b/c? backward compatible?

[18:57:40] <ronny> wheels and egges are completely different ^^

[18:57:48] <ronny> and wont work in the same contexts

[18:57:57] <ronny> eggs are the worse mess tho

[19:02:09] <rnix> ronny: you say that wheels and eggs cannot be used within the same installation?

[19:04:44] <ronny> rnix: they can be used, but they install very different

[19:05:13] <ronny> rnix: egges are encapsulated importable archies that get dropped into site and pollute sys.path

[19:05:29] <ronny> and wheels are installer packages that get unpacked as if the package was manually installed

[19:05:38] <ronny> rnix: what kinda stack do you have

[19:08:41] <rnix> zc.buildout/pyramid based

[19:10:04] <rnix> running in virtualenv

[19:13:02] <ronny> rnix: buidlout is kinda egg cenric, so you'd have to keep that

[19:13:28] <ronny> why do you need a virtualenv with buildout

[19:13:47] <ronny> the design of buildout actually makes the crutchy hacks of virtualenv unnecessary to begin with

[19:15:05] <rnix> ronny: i have lots of local development projects which have their own environment to avoid version conflictas and such

[19:15:54] <ronny> rnix: buildout makes use of eggs in a way that makes virtualenv unnecessary

[19:16:39] <ronny> imho the core ideas of buildout are utterly superior to virtualenv

[19:16:48] <ronny> but we are stuck wit that worse is better thing now

[19:16:52] <rnix> it created scripts for me which sets a ton of sys.path if thats what you mean

[19:18:29] <rnix> this things also have grown hstorically. anyway, if there is better...

[19:18:59] <ronny> if you need/want virtualenv, it might be a good idea to completely go virtualenv

[19:19:15] <ronny> that amkes some details quicker (having lots of eggs makes import __slow__

[19:20:11] <rnix> right now i'm afraid i'm stuck with what i have. so _right_now_ i need to solve my recent issue. ;)

[19:20:43] <ronny> i see

[19:24:38] <rnix> but a clean and consistent packaging/deployment setup is definitely on my todo list

[19:25:22] <ronny> hmm, its one of those items ^^

[21:23:44] <glyph> hello dstufft

[21:23:47] <glyph> dstufft: I have a Problem

[21:23:54] <glyph> hopefully you are here to talk about it

[21:24:56] <glyph> 'pip install mock==1.1.1' → installs funcsigs-0.4 mock-1.1.1 pbr-1.2.0 six-1.9.0

[21:25:07] <glyph> do the same thing again

[21:25:21] <glyph> 'pip install mock==1.1.1' → installs Jinja2-2.7.3 Pygments-2.0.2 alabaster-0.7.6 babel-1.3 docutils-0.12 markupsafe-0.23 pytz-2015.4 snowballstemmer-1.2.0 sphinx-1.3.1 sphinx-rtd-theme-0.1.8

[21:25:28] <glyph> why is this, might you ask?

[21:25:39] <glyph> mock 1.1.1 does not have a wheel published on PyPI.

[21:25:52] <glyph> when installing mock from a wheel its dependencies are different than when installing from sdist.

[21:27:09] <glyph> there's no indication of what cache pip is using when it is installing things, so it is _super_ confusing to track this down

[21:28:28] <glyph> 'pip wheel' appears to prefer the sdist

[21:28:52] <glyph> which means that when you do 'pip wheel' and then 'pip install --no-index wheels/*' it breaks

[21:34:47] <glyph> https://github.com/testing-cabal/mock/issues/269

[22:05:04] <_habnabit> https://github.com/pypa/pip/compare/develop...habnabit:extras-set-union?expand=1 is there any chance of this getting added to pip, before i actually make a merge request of it?

[22:05:19] <_habnabit> pull requests just seem so rude

[22:19:16] <glyph> _habnabit: what?

[22:19:24] <glyph> _habnabit: github culture suggests they are the most polite thing

[22:19:44] <_habnabit> glyph, ugh i don't like github culture

[22:20:01] <glyph> _habnabit: sorry, github won

[22:20:14] <glyph> _habnabit: be happy; sourceforge could have won

[22:20:19] <_habnabit> heh

[22:21:01] <glyph> _habnabit: why do you think PRs are rude? I have my own ideas, but I'm curious why you think so

[22:21:15] <sontek> PRs are like tea. You can offer someone tea but if they don't want it don't force them to drink it.

[22:21:16] <glyph> _habnabit: I tend to think they're rude because you should file a ticket first

[22:21:27] <_habnabit> glyph, it's not saying "hey, i have a problem; how should i solve it?" it's saying "HI PLZ MERGE"

[22:21:45] <_habnabit> glyph, there's no collaboration

[22:21:53] <glyph> _habnabit: right, issue first, then PR that closes it, so that the maintainer has some way to say "valid problem but your implementation sucks so bad I don't want to look at it"

[22:21:54] <_habnabit> until (maybe) after the fact

[22:21:55] <cyli> how is that different than filing a ticket, and submitting a patch along with the ticket on track or something?

[22:22:08] <_habnabit> cyli, it's not different, if you file the patch immediately with the issue

[22:22:15] <glyph> cyli: on trac, a person can submit a new patch, or divert a different branch, to the same ticket

[22:22:25] <cyli> _habnabit: do you have to wait for acknowledgement of an issue before filing a patch?

[22:22:45] <_habnabit> cyli, that's the part i'm not sure about

[22:22:46] <glyph> cyli: on github, you generally make PRs of branches on your own fork, so you either close the PR or you land it as the original submitter wants

[22:22:58] <_habnabit> cyli, imo yes

[22:23:06] <_habnabit> cyli, but i know that means a slower feedback loop

[22:23:28] <glyph> _habnabit: i'd file the ticket and submit the PR immediately; it's not rude to say "here would you like this" but it is rude to say "I don't want to explain why you should land this, just do it do it dooooo iiiiiiit"

[22:23:40] <_habnabit> glyph, sure ok

[22:23:44] <glyph> _habnabit: but, if you do file an issue, waiting to submit the patch is just holding back, slowing down the feedback cycle for the person reviewing it as well

[22:24:22] <glyph> anyway I think we are, compared to pip's maintainers, way overthinking this :) most people are just happy to have a PR, especially if your description is clear enough

[22:24:46] <glyph> most projects if they end up in the situation where there is a valid problem but they don't like the implementation strategy, are perfectly happy to copy and paste gobs of text from the PR into an issue, maybe link it (or maybe not)

[22:25:04] <cyli> _habnabit: It seems efficient to provide a solution if you happen to have one, and that lets people use your solution as a workaround until the maintainers get around to reviewing your patch

[22:25:14] <glyph> I hate that but I am willing to accept that my emoitional reaction is based on the fact that I was a process consultant for several years and it is therefore a problem with me

[22:25:21] <cyli> _habnabit: which could take months

[22:26:08] <glyph> _habnabit: cyli is considerably more in touch with the "normal" open source community on github than we are, we should probably just listen to her :)

[22:26:57] <_habnabit> i'm perfectly ok with doing that, haha

[22:27:06] <cyli> _habnabit: I'm not disagreeing with anyone about issues vs pull requests, juts my thought on submitting a bug + solution at the same time :)

[22:28:06] <cyli> maintainers could choose to ignore the solution, after all, or go with a different one.

[22:28:10] <cyli> glyph: :P no

[22:33:57] <cyli> _habnabit: although I can see what you mean - if you already submit a solution, there's a sort of social pressure on the part of the maintainers to accept it, or they might feel bad about rejecting already-done work.

[22:34:24] <_habnabit> cyli, exactly

[22:37:26] <cyli> _habnabit: I wish we could just formalize this as a social norm. :| Like if there were a well understood rule that rejecting work was perfectly valid, maybe it wouldn't be as bad? Certainly I feel better when travis or coveralls rejects a PR for me, and I can just be like "Oh, I'm sorry, but this inhuman automated system has rejected your work based on these rules that are laid out in this contributing document here. My hands are tied."

[22:37:47] <_habnabit> cyli, more automation!

[22:37:52] <_habnabit> cyli, that's the real solution

[22:38:02] <cyli> _habnabit: robots should handle awkward social situations for us

[22:53:35] <dstufft> glyph: mock is borken on 2.7

[22:53:44] <dstufft> well, it made a broken wheel

[22:53:49] <dstufft> becasue of pbr

[23:02:58] <glyph> dstufft: THE KING OF PACKAGING HAS SPOKEN

[23:03:13] <glyph> PBR IS DEPRECATED

[23:03:19] <dstufft> glyph: lol

[23:03:23] <dstufft> glyph: well pbr is fixed now

[23:03:27] <dstufft> which is why the sdist works

[23:03:36] <glyph> dstufft: but locally I have new pbr

[23:03:37] <dstufft> but the broken pbr produced a broken wheel

[23:03:44] <glyph> dstufft: and locally it's producing a broken wheel

[23:05:09] <dstufft> if you do pip wheel --no-cache-dir mock && pip install --no-cache-dir --no-index --find-links ./wheelhouse mock you get sphinx?

[23:10:46] <glyph> dstufft: let me compensate for weird environment configuration for just a second

[23:14:37] <glyph> ohhhhhh heeere we go

[23:16:40] <dstufft> did it work?

[23:16:46] <glyph> dstufft: well, virtualenvwrapper depends on pbr

[23:18:52] <dstufft> you don't work in a mktmpenv?

[23:22:01] <glyph> dstufft: I do, but I am trying to upgrade virtualenvwrapper to make sure I have recent pip in my virtualenv

[23:22:04] <glyph> and this happened:

[23:22:08] <glyph> OSError: [Errno 13] Permission denied: '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pbr'

[23:22:15] <glyph> not sure how PBR got installed globally

[23:26:23] <glyph> "pip freeze" as a user with no shell config gives me:

[23:26:23] <glyph> mercurial==3.4.2

[23:26:23] <glyph> vboxapi==1.0

[23:26:24] <glyph> wheel==0.24.0

[23:27:05] <glyph> oh crap and now I've got homebrew and system and python.org fighting each other

[23:28:05] <dstufft> dehumanize yourself and face to bloodshed

[23:32:24] <glyph> wow, this is the worst-documented meme ever

[23:37:38] <dstufft> glyph: gotta go, sorry

[23:38:08] <glyph> dstufft: I'm still working on understanding why pbr is installed, so, it's all good ;)

[23:50:58] <glyph> dstufft: perhaps the most appropriate usage of this particular meme, given the picture of the crown: http://www.keepcalm-o-matic.co.uk/p/dehumanize-yourself-and-face-to-bloodshed-2/

[23:58:02] <glyph> okay so ... pbr is _not_ installed globally

[23:59:34] <glyph> but pip is trying to uninstall it