Log file Viewer

[01:35:11] <agronholm> I'm still getting a 503 when trying to upload docs to pypi

[01:35:17] <agronholm> is this a known problem?

[07:15:09] <Seraf> Hello everyone, I have a question about the xmlrpc api search function. I want to display the author, url and some other fields. The query_package (and search function) https://bitbucket.org/pypa/pypi/src/4272c77983e871ff2b0152841758fcda90919d46/store.py?at=default#cl-869 return only a tuple with 3 fields, I was wondering why not returning all metadata or take a tuple in parameter to return the fields wanted ?

[08:14:10] <nanonyme> [Tritium], I thought 2.6-3.4 used 2005

[08:14:39] <nanonyme> Blaah, I guess this is another proof of why people should migrate to PyPy from CPython

[08:20:10] <doismellburning> yaypy

[08:20:17] <doismellburning> er, wrong channel, but yeah

[09:51:16] <[Tritium]> nanonyme: 2005 hasnt been used since python2.5

[10:39:32] <nanonyme> Whoa, now I'm totally surprised

[10:39:40] <nanonyme> Hrm

[10:41:00] <nanonyme> Anyway, CPython dependency on MSVS version is totally full of awful, means you have to have bazillion MSVS installations on your build servers. They eat *lots* of disk space with all the security updates

[17:21:27] <nedbat> any opinions on .pex files? I got a request to support them in coverage.py, which looks easy enough, but I'd never heard of .pex before.

[17:26:25] <Wooble> My opinion is that I've also never heard of them.

[17:30:03] <Yasumoto> nedbat: yep, wickman wrote most of the code

[17:30:24] <Yasumoto> I was essentially his pull request review-monkey over the pycon sprints to get it to a 1.0

[17:30:35] <nedbat> Yasumoto: are they in use? How stable are they?

[17:30:43] <Yasumoto> (any questions in particular? we've found them pretty helpful to bundle up dependencies)

[17:30:55] <Yasumoto> yep, they've been in use at twitter for ~3 years or so

[17:31:01] <nedbat> Yasumoto: are they like the output of py2exe/cx_freeze/etc?

[17:31:13] <Yasumoto> they're essentially a zipped-up virtualenv

[17:31:36] <nedbat> Yasumoto: but natively executable? like py2exe?

[17:31:39] <Yasumoto> there's a lot of extra sugar in there to pull in deps and handle executable

[17:31:57] <Yasumoto> yah, for instance we use them with Apache Aurora (for its command-line client as well as some system tools)

[17:32:03] <Yasumoto> just ./aurora_client.pex --help

[17:32:28] <nedbat> Yasumoto: and they are zip files for purposes of finding code inside them?

[17:32:51] <Yasumoto> yeah, you can just unzip -l ./aurora_client.pex

[17:33:26] <nedbat> Yasumoto: and people use them for putting code under test onto CI machines?

[17:33:45] <Yasumoto> hm.. I think they can, but that seems like an ~odd use case to me

[17:33:52] <Yasumoto> (but I don't really know the full context)

[17:34:25] <Yasumoto> they're more for building an environment- either to bootstrap an interpreter with a few dists, or for an executable with one or more entry_points/console_scripts

[17:35:13] <Yasumoto> nedbat: https://github.com/pantsbuild/pex/blob/master/docs/whatispex.rst in case you haven't seen it

[17:42:36] <wickman> pex is basically a way to package/compose/execute python environments slightly more dynamically than virtualenvs

[17:43:33] <wickman> yasumoto just clued me into the context. pex files already support coverage.

[17:44:19] <nedbat> wickman: oh. then I don't understand this: https://bitbucket.org/ned/coveragepy/pull-request/57/add-support-for-searching-inside-pex/diff

[17:45:54] <wickman> i'd like to understand what they're looking for specifically. pex supports the PEX_COVERAGE environment variable which enables coverage reporting, but it's a little wonky. see https://github.com/pantsbuild/pex/issues/89

[17:46:32] <wickman> maybe they're just unaware of PEX_COVERAGE

[17:46:39] <wickman> also coverage works fine if they just unzip the pex

[17:47:27] <wickman> e.g. unzip -d env env.pex, "coverage run -m foo env" should in theory work

[17:47:37] <wickman> does coverage support running directories, i.e. dir with __main__.py?

[17:49:39] <nedbat> wickman: yes.

[17:49:55] <nedbat> wickman: maybe you could talk with the author of the PR to see what they are looking for?

[17:49:59] <wickman> yeah.

[17:54:13] <nedbat> wickman: thanks, let me know when I can help

[19:13:34] <fcurella> Hi, i'm trying to build a wheel on OS X, but I keep getting `error: [Errno 2] No such file or directory`

[19:13:55] <fcurella> can't figure out what file it's talking about

[19:14:37] <fcurella> any idea?

[19:15:28] <fcurella> people on Linux can build the wheel, so i'm pretty sure it's environmental, not something in the package i'm trying to build

[19:18:18] <ronny> fcurella: you the one behind the fapker package?

[19:18:43] <fcurella> not the only one, but yes

[19:19:10] <fcurella> i mean, it's not *mine*, but I'm the one keeping an eye on it

[19:19:31] <fcurella> the original author is busy writing his master thesis

[19:22:45] <ronny> fcurella: im RonnyPfannschmidt on github

[19:23:27] <fcurella> lol

[19:24:32] <ronny> unfortunately i have no access to a osx box

[19:25:04] <ronny> fcurella: can you paste your *complete* output of python setup.py bdist_wheel somewhere

[19:25:24] <ronny> also update the wheel and the setuptools package

[19:27:36] <fcurella> https://gist.github.com/fcurella/fb6b2839afa334836744

[19:27:51] <fcurella> wheel ans setuptools pagackes are already up-to-date

[19:28:27] <ronny> also brb, have to run for the shop before it closes, forgot a ingredient

[19:28:37] <fcurella> no problem

[19:40:44] <ionelmc> fcurella: try using hunter or https://docs.python.org/3/library/trace.html to figure out what exactly raise the error

[19:47:32] <ronny> fcurella: you are on the osx defauly python2.7?

[19:48:05] <fcurella> ronny: no, i've installed python 2.7.10 via pyenv

[19:51:22] <ronny> fcurella: i see, can you make a virtualenv perhaps and try again, i suspect you are hitting a subtle platform bug

[19:52:09] <fcurella> i did create the virtualenv with `pyenv virtualenv`

[19:53:32] <ronny> fcurella: hmm, i suspect you will need help of someone with osx, i cant experiment due to lack of hardware

[19:54:18] <fcurella> thank you ronny, i appreciate you taking the time to help

[19:54:38] <fcurella> I'll see if I can track anything with hunter

[19:56:06] <ronny> fcurella: good luck

[19:56:13] <fcurella> thanks :)

[20:04:18] <ionelmc> fcurella: try filtering on kind="exception"

[20:04:28] <ionelmc> otherwise you get ridiculous amounts of output :)

[20:04:30] <ionelmc> btw

[20:04:48] <ionelmc> is there a good way to find out if a module/package is from stdlib or not?

[20:05:22] <ionelmc> i'm thinking about using distutils.sysconfig.get_python_lib() to exclude site-packages but meh ...

[20:11:48] <fcurella> O_O

[20:12:01] <fcurella> somehow now it works

[20:15:07] <fcurella> n/m, i forgot the bdist_wheel part

[20:16:27] <fcurella> ionelmc: something like `PYTHONHUNTER="kind='exception'" python setup.py sdist bdist_wheel`?

[20:16:38] <ionelmc> yup

[20:17:18] <ionelmc> you might get swamped in output and need for some redirect to file

[20:21:25] <fcurella> this looks suspicious: `subprocess.call([os.environ['WHEEL_TOOL'], 'sign', wheel_name])`

[20:22:43] <fcurella> $ head /usr/local/share/python/wheel

[20:22:49] <fcurella> #!/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

[20:22:53] <fcurella> ಠ_ಠ

[20:25:19] <fcurella> \o/ hurray

[20:25:22] <fcurella> thanks ionelmc

[20:25:39] <ionelmc> wooot

[20:25:46] <ionelmc> what did you find?

[20:26:15] <fcurella> i had `export WHEEL_TOOL=/usr/local/share/python/wheel` in my bash_profile

[20:26:51] <fcurella> and `/usr/local/share/python/wheel` was using `/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python` as the interpreter

[20:27:02] <fcurella> which is not a thing anymore on my system

[20:27:21] <fcurella> that's prob. 2 OS X versions ago

[20:27:41] <fcurella> so that's the one file it couldn't find. System Python 2.7.3

[20:27:53] <Berra> So why would installing requires from git repositories be deprecated? Isn't it a great idea?

[20:28:23] <fcurella> unset the env var removed the override, and setuptools now uses wheel from the venv

[20:29:43] <fcurella> weee! Now I can make wheels! :P

[20:56:58] <tomprince> Berra: Installing from git repositories is fine.

[20:57:35] <tomprince> It is dependency links that is deprecated (although I don't think there is a time frame for removal, currently.

[20:58:13] <tomprince> Part of the issue is that it allows arbitrary packages to replace other packages (by including dependency links for them).

[20:59:25] <Berra> tomprince: I so wouldn't it be best to allow a Require to be hard-specified as a gitrepo, so that the ambiguity between a pypi package and a repo is impossible?

[20:59:48] <Berra> Put the giturl in the requires right way

[21:04:42] <tomprince> There may have been talk of that, I'm not sure.

[21:04:58] <tomprince> That is part of why dependency-links hasn't been removed yet.

[21:05:22] <tomprince> I don't think it will be removed until there is a good story to replace it, for the use cases where it makes sense.

[21:08:04] <Berra> Being able to just drop a git repo url in the requires feels perfect.