pmxbot IRC Log Viewer

[05:25:45] <dstufft> tdsmith: btw, released pip 6.1.0

[05:27:06] <tdsmith> nice, thanks

[07:12:01] <apollo13> dstufft: \o/ -- I am already on 6.1.0 thanks to the version check :þ

[07:17:09] <dstufft> apollo13: success!

[07:24:42] <tdsmith> python and python3 updated in homebrew in ee9f75a

[07:26:01] <tdsmith> hmm, dstufft: https://www.dropbox.com/s/d9smvn50knz08rr/Screenshot%202015-04-07%2000.25.17.png?dl=0

[07:26:34] <tdsmith> downloaded 6.1.0, installed 6.0.8?

[07:26:46] <dstufft> tdsmith: it's wrong, there's some bug that only sometimes happens

[07:26:56] <dstufft> if you do pip --version it'll be 6.1.0

[07:27:52] <tdsmith> well, then i ran pip install -U pip again: https://www.dropbox.com/s/qdazinz8ddkzbqx/Screenshot%202015-04-07%2000.26.39.png?dl=0 -- it says "uninstalling pip-6.0.8" ?

[07:27:57] <tdsmith> god knows i'll never be able to repro this

[07:29:15] <apollo13> well you did not think that you could just skip 6.0.8, did you?

[07:29:50] <tdsmith> in my hubris... :p

[07:30:12] <dstufft> tdsmith: oh, hrm

[07:30:14] <dstufft> that's odd

[07:30:26] <dstufft> tdsmith: can you file a bug

[07:31:47] <tdsmith> i think i might have had a 6.0.7 egg and a flat 6.0.8 installed

[07:32:44] <dstufft> ah

[07:32:46] <dstufft> that mamkes sense

[07:33:55] <ronny> dstufft: what are you doing awake at thi "unholy" time in your timezone?

[07:34:03] <apollo13> is there any way to get pillow tell me which image type it supports now that pip install hides that info :þ

[07:34:35] <ronny> btw, it seems like i can announce gumby elf by the end of the month ^^

[07:34:59] <dstufft> ronny: I don't have a normal sleep schedule, so my hours I'm awake are all over the place

[07:35:11] <dstufft> plus I work from home, so if I need to take a nap i can take an hour or two nap easily

[07:36:01] <tdsmith> i was about to ask the same thing :p

[07:36:33] <tdsmith> you're right, dstufft, the "Successfully installed" message is lying

[07:36:48] <tdsmith> can reproduce this in a virtualenv, though; should i file an issue?

[07:38:08] <ronny> dstufft: btw, how does pip manage the uninstall of scripts from wheel packages, those shouldnt be part of RECORD ?

[07:38:26] <ronny> (im trying to understand how to propperly handle scripts generated from things not in record directly)

[07:39:08] <dstufft> ronny: I think pip updates the RECORD to include them

[07:39:16] <dstufft> tdsmith: yes please file an issue

[07:43:39] <ronny> dstufft: i see

[08:00:16] <ronny> dstufft: btw, could pip be taught to use source packages that have no setup.py in some way?

[08:00:56] <dstufft> ronny: that's a long term goal, It hasn't been high on anyones list though

[08:01:19] <ronny> dstufft: i see, i need it for gumy elf ^^

[08:01:24] <ronny> *gumby

[08:01:32] <jck> !logs

[08:01:32] <pmxbot> http://chat-logs.dcpython.org/channel/pypa

[08:06:24] <ronny> dstufft: btw, whats you oppinion on reusing package.json to also specify the python package?

[08:06:42] <dstufft> not sure what you mean

[08:09:18] <mgedmin> apollo13, /me too!

[08:13:38] <ronny> dstufft: in gumby elf i use a package.json with the key "python package" to store metadata and so on

[08:22:31] <mgedmin> apollo13, filed https://github.com/python-pillow/Pillow/issues/1182 for this

[08:22:54] <apollo13> mgedmin: <3

[08:22:59] <dstufft> ronny: oh, the concept in general? I don't think it's likely that it's going to be an official thing, I don't personally like it much - but the way I want to go with things is that the build tool is completely pluggable so it's entirely up to developers what they want the "UX" to be for their build tools

[08:23:05] <mgedmin> ha ha https://pip.pypa.io/en/stable/news.html claims 6.1.0 is "unreleased"

[08:25:02] <dstufft> mgedmin: yea, I forgot to bump that when I cut the release

[08:25:13] <dstufft> I'm not gonna issue a new release just for that though, I already fixed it in the repo

[08:25:24] <mgedmin> sure

[08:25:42] <mgedmin> I did that once or twice myself

[08:26:21] <mgedmin> (this is why my 'make release' generally checks my changelog with horrible Makefile magic: https://github.com/mgedmin/objgraph/blob/master/Makefile#L106-L108)

[08:26:50] <ronny> reminds me that i need something like that in gumby elf ^^

[08:27:12] <ronny> dstufft: i suppose you'd prefer a setup.cfg?

[08:27:52] <dstufft> ronny: myself personally? probably a yaml file. I don't find json files very friendly for a human to edit and ini files are kinda crummy.

[08:28:13] <dstufft> internally no matter what it is, it'll get compiled down to JSON inside of the sdist or wheel (long term)

[08:28:19] <ronny> dstufft: i see, yaml is tricky, because its so magical, i get really strange issues sometimes

[08:29:44] <dstufft> ronny: yea, I'm not entirely happy with YAML, but I think it's the least worst option for a human editable file

[08:29:44] <apollo13> haha

[08:29:56] <dstufft> that or just a python file

[08:30:15] <apollo13> ronny: what is this gumby?

[08:30:20] <dstufft> an executable file isn't that big of a deal in the future (tm) when it's only used on the developer machine to generate a sdist

[08:31:00] <ronny> apollo13: my take at developer facing packaging tools

[08:31:00] <doismellburning> I think it's worth distinguishing between "YAML as a serialization format" and "YAML as a human-writable structured data format"

[08:31:07] <apollo13> ronny: link?

[08:31:12] <doismellburning> and for the latter, I really like it

[08:32:09] <ronny> apollo13: https://bitbucket.org/RonnyPfannschmidt/gumby_elf , currently only has a develop command (however one that supports pip uninstall)

[08:36:19] <xafer> hello, https://github.com/pypa/pip/pull/2629 should be ok to review/merge :)

[08:40:01] <xafer> will rebase it to deal with conflicts

[08:42:07] <ronny> dstufft: btw, do you have any writeups on the yaml format you'd like?

[08:42:33] <dstufft> ronny: nope, haven't thought much on it because I've been working backwards from the other side

[08:42:48] <dstufft> I just know I don't like json or ini as a human writable file

[08:43:00] <dstufft> no comments in JSON and things like no trailing commas and stuff is user hostile

[08:43:03] <dstufft> and ini is a non standard

[08:43:06] <ionelmc> ronny: how does that develop even work? it has a bootstrapper that just execs a file - what does it do about sys.path?

[08:43:09] <doismellburning> dstufft: absolutely

[08:52:29] <ronny> dstufft: i see

[08:52:44] <ronny> ionelmc: lone-elf only installs the dependencies, then runs its own develop command

[08:53:39] <ionelmc> ronny: that i saw

[08:53:48] <ionelmc> the question is about boostrapping

[08:53:59] <ronny> and the develop install installs a python file in site-packages that will exec the development root module and is uninstallable via pip

[08:54:07] <ionelmc> let me rephrase: about making the package importable

[08:54:29] <ionelmc> and subpackages/modules

[08:55:30] <ronny> ionelmc: the __init__.py thats written out sets the __path__ and __file__ of the module, then execfiles the __file__ thats in the real worktree

[08:55:47] <ronny> from that one it can import subpackes/submodules because of __path__

[08:56:03] <ionelmc> ronny: so that's enough to trick the import system?

[08:56:35] <ionelmc> interesting

[08:56:40] <ionelmc> does it work on all pythons?

[08:56:56] <ronny> ionelmc: its not tricking, its specifically using the __path__ feature of a "module" to act as a "package"

[08:57:31] <ronny> it completely works around the issues of putting a worktree into sys.path

[08:57:55] <ronny> because it puts a file into site-packages that is pip uninstall-able

[08:57:58] <ionelmc> ronny: but you don't need to put the worktree, just the src dir

[08:58:20] <ronny> ionelmc: note how the src dir does not contain gumby_elf

[08:58:40] <ronny> src not being importable directly is also deliberate

[08:58:49] <ionelmc> aaah :)

[08:58:52] <ionelmc> doh

[08:59:03] <ronny> you sould only be able to import develop/real installs

[08:59:22] <ionelmc> so why do you have a `src` package?

[08:59:58] <ronny> ionelmc: src is not a "package" src is a filder to put the package content in

[09:00:15] <ronny> *folder

[09:00:15] <ionelmc> well it has an __init__.py in it - therefore it's a package

[09:00:35] <ronny> so?

[09:00:50] <ronny> it deliberately has the wrong name

[09:00:55] <ionelmc> i thought you gonna have slightly different layout

[09:01:15] <ronny> what do you mean?

[09:01:23] <ronny> im open to change it atm ^^

[09:01:37] <ionelmc> eg: ./src/gumby_elf/__init__.py

[09:02:27] <ionelmc> but that also means you support dists with multiple root-module/packages

[09:02:29] <ronny> ionelmc: i had that initially, but when experimenting with layouts, and import issues, i concluded it would be best to make it deliberate in that way

[09:04:07] <ionelmc> ronny: how come you picked that bootstraper file over a pth file?

[09:05:43] <ronny> ionelmc: pth files cant sanely rename modules, and always add to sys.path, bootstrapers keep sys.path lean and support a more free layout wrt the src folder

[09:06:39] <ionelmc> ronny: ok yeah, but that's a flaw of your file layout, not pth per se

[09:07:14] <ronny> ionelmc: the flaw is deliberate, to prevernt pushing a sorce tree into sys.path directly (had too many issues with it)

[09:07:39] <ionelmc> so my problem with your current layout is that it's hard to port projects to it, or move back to setuptools if needs be

[09:08:04] <ionelmc> i'd rather see a ./src/gumby_elf/__init__.py

[09:09:08] <ionelmc> if you have that you only need to push ./src on sys.path, not the working tree (.)

[09:09:29] <ionelmc> and you don't need to have that weird bootstrap module anymore

[09:10:58] <ronny> ionelmc: i'd still need the bootstrap module to run the develop command for the first time

[09:11:19] <ronny> hmm

[09:11:26] <ronny> hmm

[09:11:32] <ionelmc> ronny: you have 2 boostrap things

[09:11:54] <ronny> but i suppose i coudle replace package.py with package.pth

[09:11:57] <ronny> *could

[09:12:14] <ronny> hmm

[09:13:06] <ronny> ionelmc: yup, im convinced now that i should put the package name into the src folder and use a recorded pth file instead of a bootstrap python file

[09:13:50] <ronny> thanks :)

[09:15:59] <haypo> hi. is pip 6.1 released or not? https://pypi.python.org/pypi/pip points to 6.1, but https://pip.pypa.io/en/stable/news.html says "6.1.0 (unreleased)"

[09:17:07] <ronny> haypo: news was accidentially not updated. it will be fixed later

[09:17:19] <ronny> the fix is already committed

[09:17:56] <haypo> an openstack scripts uses InstallRequirement.url, but it looks like the attribute is gone (it is still available in 6.0.8) :-(

[09:25:38] <xafer> should be InstallRequirement.link.url now I think

[09:26:25] <dstufft> haypo: there's a patchset against openstack stuff that updates it

[09:26:27] <dstufft> or two

[09:30:00] <haypo> pip doesn't provide a stable API or something like that?

[09:30:09] <haypo> for openstack, there is an open issue: https://bugs.launchpad.net/tempest/+bug/1440984

[09:31:27] <ionelmc> haypo: why do you guys even use that? isn't it some internal thing in pip ?

[09:31:41] <dstufft> haypo: No, pip has no API other than the CLI. There is an open ticket or two about providing one, but it requires someone to enumerate what they actually need in an API

[09:32:19] <haypo> ionelmc, the script is here, https://github.com/openstack/requirements/blob/master/update.py

[09:33:14] <haypo> ionelmc, i don't know this script. it looks to be used to update requirements.txt in other projects

[09:33:32] <ionelmc> fun times :-)

[09:33:38] <haypo> ionelmc, when a dependency is upgrade in openstack, it's first upgraded in openstack/requirements which contains all dependencies with all versions

[09:33:54] <haypo> then, other projects are updated from openstack/requirements with update.py

[09:34:17] <ionelmc> haypo: so there's a single requirement set for *all projects* ?

[09:34:25] <haypo> ionelmc, openstack is very complex, it has more than +230 dependencies: https://github.com/openstack/requirements/blob/master/global-requirements.txt

[09:35:03] <ionelmc> haypo: it's not that big

[09:35:06] <dstufft> ionelmc: because pip doesn't properly handle multiple things depending on the same thing, openstack has a work around where they list the exact specifier tou're allowed to use for each dependency

[09:35:06] <haypo> ionelmc, global-requirements.txt is a global policy for versions. it's common to require a minimum version and sometimes to exclude some versions

[09:35:09] <ionelmc> i have 200 deps in my project

[09:36:05] <ionelmc> tho it's split in just 2 monoliths

[09:37:12] <ronny> sounds fun ^^

[09:37:42] <ionelmc> haypo: how does openstack know what projects use what deps?

[09:38:14] <ionelmc> eg: if I maintain the global-req.txt, how do i know what projects use what?

[09:38:23] <haypo> ionelmc, update.py parses requirements.txt of a project and then updates versions of each line (i'm not sure, but i guess that it does something like that)

[09:38:30] <haypo> ionelmc, each project has its own requirements.txt

[09:38:37] <ionelmc> because i can't be looking at all the req.txt from all the many small projects

[09:38:46] <haypo> example for nova: https://github.com/openstack/nova/blob/master/requirements.txt

[09:39:12] <ionelmc> haypo: i got that, i'm asking about the global req.txt

[09:39:57] <haypo> ionelmc, sorry, i don't understand your question

[09:40:43] <haypo> dstufft, "No, pip has no API other than the CLI" too bad :-(

[09:40:44] <ionelmc> haypo: as a maintainer of https://github.com/openstack/requirements/blob/master/global-requirements.txt how can i know what projects are going to be affected if i change versions for a dependency?

[09:41:13] <dstufft> ionelmc: openstack has a massive CI system, I don't think any change to that file can happen without running the tests across a bunch of things

[09:43:52] <haypo> ionelmc, requirements.txt of each component is not updated immediatly. a bot proposes to update requirements.txt, and we have extensive tests for each pull request

[09:44:02] <ionelmc> dstufft: i'm only asking about the process, i don't doubt their tests :)

[09:44:14] <haypo> ionelmc, if we notify a failure, it's then fixed in the project, or the global requirements is modified

[09:44:44] <haypo> as any other pull requests, it requires two +2 votes to be approved

[09:44:52] <haypo> (only core developers can vote +2)

[09:46:04] <ionelmc> haypo: so how does the maintainer of https://github.com/openstack/requirements/blob/master/global-requirements.txt decide to update a dependency there?

[09:46:09] <ionelmc> is there a process for that?

[09:46:52] <ionelmc> i'm asking because this info is hard to find out, if you can point me to process docs i don;t mind :-)

[09:47:09] <dstufft> the process is basically "someone submits a patchset that updates it"

[09:47:15] <dstufft> I don't think there's anything more formal than that

[09:48:02] <haypo> i don't know if there is a bot to propose to update global-requirements.txt

[09:48:13] <haypo> i already sent multiple pull requests to update global-requirements.txt for a specific dependency

[09:48:40] <ionelmc> makes sense

[09:48:52] <ionelmc> now i see that there are 204 contributors to that file

[09:50:28] <ionelmc> now i see that the reqs there are "abstract"

[09:50:36] <ionelmc> haypo: are they pinned at some point?

[09:50:45] <ionelmc> *version pinned

[09:51:47] <dstufft> openstack uses the requirements.txt as an input to install_requires

[09:51:51] <dstufft> much to my dismay :)

[09:52:15] <ionelmc> wat, no pinning at all!?

[09:52:28] <haypo> ionelmc, there are issues with stable branches, because dependencies of dependencies are not pinned

[10:02:38] <haypo> ok, i just hitted a second issue: "pip install argparse" doesn't work anymore

[10:02:57] <haypo> so i cannot use devstack anymore because of that

[10:04:26] <haypo> when was pip 6.1 released?

[10:13:32] <jhermann> isn't it nice when you are about to ask for a feature, and it's already in there? :)

[10:13:47] <jhermann> dstufft, :thumbsup: for -r taking URLs

[10:15:22] <dstufft> haypo: it was released a few hours ago

[10:15:53] <haypo> dstufft, oh, it already bites me :)

[10:16:08] <haypo> FYI i opened https://bugs.launchpad.net/keystone/+bug/1441083 for the argparse issue

[10:16:34] <dstufft> haypo: open an issue on pip please

[10:16:50] <dstufft> that's an unexpected side effect of a change I was on the fence on anyways

[10:16:59] <haypo> dstufft, maybe later, right now i just cannot work, so i have to fix devstack :-p

[10:17:01] <dstufft> I'll just revert it and cut a 6.1.1

[10:18:19] <haypo> dstufft, i don't know anything about pkg_resources. can you explain me how it checks dependencies at runtime? where are these dependencies stored? could you please see the traceback at https://bugs.launchpad.net/keystone/+bug/1441083 ?

[10:22:01] <haypo> oh, i found /usr/lib/python2.7/site-packages/pysaml2-2.4.0-py2.7.egg-info/requires.txt:argparse using strace+grep :)

[10:23:04] <haypo> too bad, pysaml2 is not maintained by openstack, and its setup.py contains install_requirements=[..., 'argparse', ...]

[10:24:23] <dstufft> haypo: https://github.com/pypa/pip/pull/2650 should fix it

[10:24:45] <haypo> dstufft, is it possible to use environment markers in the install_requirements parameter of setup()?

[10:26:43] <haypo> dstufft, thanks! i completed https://bugs.launchpad.net/keystone/+bug/1441083 with pysaml & your pull request

[10:32:52] <dstufft> haypo: I added a (temporary) shim for he update.py problem too

[10:33:01] <dstufft> haypo: that attribute will be gone in the _next_ release

[10:38:34] <jhermann> haypo, it's Python, you can do anything you want, as long as it works ;)

[11:07:54] <ionelmc> dstufft: https://bootstrap.pypa.io/get-pip.py didn't update yet (for 6.1.0) right?

[11:08:03] <ionelmc> *6.1.1

[11:11:46] <xafer> haypo, environments markers inside setup() are done via extras_require, cf https://bitbucket.org/pypa/wheel/src/bdf053a70200c5857c250c2044a2d91da23db4a9/setup.py?at=default#cl-41

[11:12:09] <dstufft> ionelmc: probably not, it auto updates every so often

[11:12:30] <dstufft> ionelmc: but it'll still install 6.1.1, the updating just matters for what version is bundled inside of get-pip.py

[11:13:23] <dstufft> tdsmith: btw I released a 6.1.1 to deal with unexpected breakage

[11:18:49] <ronny> hmm

[11:21:35] <haypo> dstufft, "btw I released a 6.1.1 to deal with unexpected breakage" thank you so much!

[11:21:59] <haypo> dstufft, any idea how we can avoid such issues in the future? it's not the first time that a pip release "broke" openstack

[11:22:45] <dstufft> haypo: little bit of openstack not touching internals so much, a little bit of getting better tests in pip itself. PAckaging as a bit of a postel's tarpit effect going on so it's hard to make any changes without breaking _someone_

[11:22:56] <dstufft> and openstack does crazier things than most

[11:24:14] <haypo> dstufft, maybe openstack should provide you a CI to always test openstack with the development version of pip?

[11:25:47] <haypo> dstufft, using pip 6.1.1, i get -> AttributeError: 'NoneType' object has no attribute 'url'

[11:26:06] <nanonyme> Would anyone happen to know whether you can instantiate classes and call their methods as entry_point?

[11:26:14] <haypo> dstufft, oh, wait, the full traceback: http://paste.openstack.org/show/199343/

[11:26:54] <haypo> dstufft, your workaround property doesn't work if link is None. you need something like return getattr(self.link, 'url', None)

[11:27:13] <ionelmc> dstufft: haypo: pre-releases could help, if openstack would test them first

[11:27:37] <haypo> ionelmc, openstack has a team of people *paid* to ensure that openstack tests are running well

[11:27:50] <haypo> ionelmc, you should try to contact them, for example, you can join #openstack-infra

[11:29:04] <ionelmc> haypo: well they could test the git branch then, if they are really paid, dstufft has announced 6.1.0 a month ago or something

[11:30:13] <haypo> ionelmc, (well, i'm not 100% sure that there is a team paid to run the CI)

[11:30:22] <ionelmc> just saying, openstack's fault is they did not test the upcoming release code

[11:30:33] <haypo> ionelmc, it's a communication issue ;)

[11:32:41] <haypo> dstufft, i checked getattr(self.link, 'url', None), it worked for me

[11:33:09] <linovia> dstufft: are there already written plans / discussion about the pip test suite improvement ?

[11:33:26] <haypo> ionelmc, i don't want to say that the fault comes from pip or openstack, i don't care

[11:33:29] <ionelmc> haypo: iow, if only openstack has issues with packaging tools then maybe openstack is doing something wroooong

[11:33:38] <haypo> ionelmc, i'm trying to find a solution to avoid regressions in the future

[11:34:15] <dstufft> eh

[11:34:18] <ronny> ionelmc: openstack uses the internals of something which has the cli as official "api" ^^

[11:34:20] <dstufft> it's a little bit on both sides

[11:34:33] <dstufft> there's some of that, there's some of just we break them

[11:34:37] <dstufft> it happens

[11:34:59] <haypo> ionelmc, "if only openstack has issues with packaging tools" the argparse issues comes from pysaml2. with pip 6.0.8, it was possible to install & use pysaml2. with pip 6.1.0, it's no more possible

[11:35:01] <dstufft> I hang out in #openstack-infra so I tend to try and sort out where things need fixed there

[11:35:53] <ionelmc> ronny: neeeever seen that before! ;-)

[11:35:54] <haypo> IMO the real issue is that PyPI has almost 57.700 packages, and that pip has too few tests

[11:36:26] <dstufft> linovia: there's no written plans beyond "we need better tests"

[11:37:33] <ionelmc> "better tests" as in "high threshold for pain"?

[11:37:45] <ionelmc> xD

[11:38:23] <haypo> dstufft, just to know, do you plan to release 6.1.2 with a fix for InstallRequirement.url property?

[11:39:41] <dstufft> haypo: don't think so, sounds like #openstack-infra has it covered anyways

[11:39:41] <ronny> fmm, pip is a bit of a mess ^^

[11:39:50] <dstufft> I only tossed that bit in at the last minute

[11:39:52] <linovia> dstufft: I'm interested in helping there though I don't know where I would start and how time I can spend on this

[11:41:02] <haypo> dstufft, a fix is under review https://review.openstack.org/#/c/171060/

[11:43:29] <ionelmc> ronny: you dared to read it's __init__.py?!

[11:49:15] <nanonyme> So, no entry_point gurus present to tip what syntax you have to use to instantiate classes during entrypoints? :/

[11:51:08] <ronny> nanonyme: unintended per design, handleable via getattr hacks and using mymodule:wrapperobj.realobj to do the call

[11:51:56] <nanonyme> Bläh. Why is it unintended?

[11:52:31] <linovia> can't this be done by instantiating the the class in the module and calling the instance in the setup ?

[11:52:40] <ronny> nanonyme: an entrypoint shows an object that is obrainable via import + recursive getattr

[11:53:02] <ronny> nanonyme: calls are not part of that

[11:53:05] <nanonyme> linovia, well, the "right" way would be to turn the method into a classmethod

[11:53:13] <ronny> nanonyme: whats the final use-case?

[11:53:28] <ronny> nanonyme: in ase of doub, just make a _foo function and use that in the ep

[11:53:40] <nanonyme> But this isn't my project and changing the method to classmethod would be a pretty drastic change

[11:54:15] <linovia> nanonyme: you class method could also do as ronny said and instantiate the class + call your function

[11:54:40] <linovia> nanonyme: and I'm not convinced a class method is the right way to go

[11:55:07] <nanonyme> ronny, basically there's a AssistantClass which has a method main(). This used to be done by having a separate script that instantiated it and called main

[11:55:31] <haypo> dstufft, a workaround for the .url attribute has been commited. update.py now works with pip 6.0.8, pip 6.1 and 6.1.1

[11:55:38] <ronny> nanonyme: just make a function that does that?

[11:55:39] <nanonyme> And scripts=[] then included this helper script

[11:55:54] <haypo> dstufft, it looks like all pip 6.1 issues in openstack have been fixed (quickly), cool!

[11:55:56] <ionelmc> nanonyme: metaclasses!

[11:56:37] <ionelmc> xD

[11:56:50] <ionelmc> "what could go wrong"

[11:57:05] <linovia> meta-evil

[11:57:11] <ronny> *insert a all the things meme picture here*

[11:57:39] <ionelmc> nanonyme: so it's either me getting stabbed cause you use a metaclass, or you just fix your methods

[11:58:04] <nanonyme> ronny, ends up messy. Most likely cleanest would be to make main() a classmethod and call everything inside main() on the created instance instead of self

[11:58:21] <ronny> nanonyme: you can do that as well

[11:58:35] <ionelmc> damnit now I have this urge to describe the metaclass solution

[11:58:39] <nanonyme> I'm pretty sure it's the best way to do it but it's also the most invasive way to do it :)

[11:58:45] <ionelmc> it's only 3 lines of code

[11:58:59] <nanonyme> Since I'd have to rewrite most of main() plus everything that calls main()

[11:59:12] <ronny> nanonyme: whats wrong with adding a global function that starts with a underscore and a comment 'this will go away'

[11:59:24] <ionelmc> ronny: how long is that sword? will i survive?

[11:59:41] <nanonyme> ronny, will it?

[12:00:00] <ronny> ionelmc: 300m, please let the surrounding blocks evacuate

[12:00:18] <nanonyme> ronny, plus then I'd have to duplicate the function signature or use *args, **kwargs which is always a bit merh

[12:00:21] <ronny> nanonyme: that depends on what you do later, but its the most simple way to make things work

[12:02:00] <nanonyme> Hooooly moly, this main() is just scary...

[12:02:27] <nanonyme> Totally an example of how you do not use classes :)

[12:02:40] <nanonyme> (hadn't yet read all of it)

[12:05:18] <ionelmc> nanonyme: ronny: now that i think of it, it can be solved with just a descriptor

[12:14:54] <ionelmc> nanonyme: ronny: here we go https://ideone.com/UtYYj3

[12:15:24] <ionelmc> now i hope you appreciate the fact that it's py3 and can't be used right away xD

[12:16:26] <ronny> lol

[12:16:28] <ionelmc> ronny: and now you have a reason to visit!

[12:16:47] <ronny> heh

[12:17:05] <ronny> ionelmc: but your masterplan has a fatality flaw

[12:17:16] <ionelmc> tho getting that sword on the plane with be a problem

[12:17:35] <ronny> duct-taped on top

[12:18:30] <ionelmc> ronny: what? you can't duct-tape a duct-tape!

[12:20:57] <ronny> i have meta-duct-tape

[12:21:46] <nanonyme> Right right...

[12:24:05] <ronny> its a byproduct your tear glands produce as you hack on setuptools

[12:24:45] <ionelmc> ronny: but you avoid it

[12:24:53] <ionelmc> maybe it's the fear glands

[12:25:03] <ionelmc> hahah

[12:27:18] <ronny> try making that joke after hacking on setuptools ^^

[12:28:56] <ionelmc> ronny: do custom setup.py commands count?

[12:29:26] <ronny> ionelmc: nope, 2 orders of magnitude less pain at least

[12:39:35] <ionelmc> https://twitter.com/ionelmc/status/585421294738505728

[12:39:54] <ionelmc> nanonyme: now say you regret asking that question :-p

[12:52:53] <haypo> ionelmc, dstufft : oh, i patch to "attempt to stop using pip internals" https://review.openstack.org/#/c/171157/

[13:41:52] <pf_moore> Is it weird that using a pip session to get https://pypi.python.org/simple takes longer than just using requests.get()?

[13:44:18] <pf_moore> I was trying to use pip's cache to avoid hitting the net, and I built a session by nicking the code from pip.basecommand (_build_session)

[13:45:03] <pf_moore> But doing len(session.get().text) takes about 2 secs with that session, whereas len(requests.get().text) takes about 1 sec...

[13:57:04] <ionelmc> pf_moore: maybe you could profile it, or trace it?

[13:57:36] <ionelmc> pf_moore: give https://pypi.python.org/pypi/hunter a shot

[14:01:51] <pf_moore> ionelmc: possibly, but I don't really want to go digging into the pip internals here. This isn't a huge "my code is too slow" issue, I just thought that seeing as I have this bunch of downloaded stuff pip maintains, maybe it'd be good to use it.

[14:02:23] <pf_moore> I was just surprised to be that wrong - "not noticeably faster" I could accept, but slower seems odd.

[14:03:19] <pf_moore> Given that a pip session isn't really intended for use outside of pip's code, I'm not expecting much. I wonder if the cache is keyed off the program name somehow?

[14:05:08] <pf_moore> Looks like my code isn't even reading the pip cache files. (The last access time didn't change).

[14:05:37] <pf_moore> So the problem is that I'm not building the session correctly. Hardly a surprise.

[14:06:52] <pf_moore> It would be nice if pip had a supported "build a session" API to let 3rd party code make use of the pip cache.

[14:30:45] <pf_moore> yep, it was the default values for the various session options. I wasn't picking up the right defaults to match pip.

[14:31:24] <pf_moore> 0.05 sec vs 2 sec is a much better ratio (cache: non-cache).

[23:11:54] <thorie> hello.. anyone seen this pip error before? Exception __init__.py", line 236 ... http://pastebin.com/kKi5YEHX

[23:16:03] <thorie> it only started happening after i upgraded my robotframework pip package

Log file Viewer

Help | Karma | Search:

#pypa logs for Tuesday the 7th of April, 2015