pmxbot IRC Log Viewer

[01:06:39] <dstufft> qwcode: https://www.pypa.io/en/latest/

[01:06:57] <dstufft> qwcode: the redirect from pypa.io to www.pypa.io should come up once DNS catches up too

[01:07:28] <qwcode> dstufft, awesome, thanks

[01:08:53] <qwcode> will handle the merges later

[01:11:27] <dstufft> qwcode: all we have on our own infra is bootstrap.pypa.io and some redirects, instead of managing our own salt infra I'm going to just move the pypa sites over to the python infra

[01:11:36] <dstufft> it won't break anything you're doing though

[01:11:38] <dstufft> just letting you know

[09:24:43] <jezdez> so I was wondering if we should start to actual use the twitter account more to get attention to things like the questions dstufft has asked recently there?

[09:24:59] <jezdez> maybe I should ask on the mailing list

[16:07:09] <msabramo> +1 for twitter, but what is the account? :-)

[16:07:15] <msabramo> pypa?

[16:09:42] <msabramo> that doesn't seem right

[16:10:05] <msabramo> nor does pip

[18:49:34] <msabramo> latest version of pip on git develop is caching wheels? where?

[18:49:50] <msabramo> $ pip install ipython

[18:49:50] <msabramo> Downloading/unpacking ipython

[18:49:51] <msabramo> Using cached ipython-2.3.1-py27-none-any.whl

[18:49:52] <dstufft> msabramo: it's caching all HTTP access

[18:49:58] <dstufft> msabramo: what OS are you on

[18:50:01] <msabramo> OS X

[18:50:07] <dstufft> ~/Library/pip/caches/http

[18:50:09] <dstufft> IIRC

[18:50:12] <dstufft> er

[18:50:13] <msabramo> interesting

[18:50:18] <dstufft> ~/Library/Caches/pip/http

[18:50:22] <dstufft> or something like that

[18:50:28] <msabramo> this going to kill pip-accel and things like that?

[18:50:45] <msabramo> does it use some kind of caching add-on for requests or something?

[18:50:57] <dstufft> well

[18:51:01] <dstufft> it just caches network access

[18:51:11] <dstufft> and it follows CacheControl headers

[18:51:17] <msabramo> it might be nice if it printed out the cache location, if it knows that, in case folks want to bypass or remove

[18:51:42] <msabramo> ~/Library/Caches/pip is correct

[18:52:02] <dstufft> you pretty much have to clear the entire cache

[18:52:08] <msabramo> oh great, it's some opaque structure with guids

[18:52:09] <dstufft> there's not really a good way to purge a single item

[18:52:18] <dstufft> it's a hash of the request

[18:52:35] <msabramo> ooh let me try --no-cache-dir Disable the cache.

[18:52:53] <dstufft> that won't delete anything ofc

[18:53:00] <dstufft> it'll just turn off using the cache

[18:53:04] <msabramo> voilà there we go

[18:53:10] <msabramo> yeah I don't actually need to delete

[18:53:27] <msabramo> I just want to force it to do the whole install so I can reproduce something

[18:53:57] <msabramo> I love the new progress bar by the way

[18:54:18] <msabramo> I have toyed with the idea of making it use a fancy progress bar like pytest-sugar has

[18:54:34] <msabramo> that does magic with Unicode characters to make it look like an actual bar

[18:56:18] <dstufft> the thing we're using has the ability to do that

[18:56:32] <dstufft> just switch out the class it derrives from

[18:56:49] <dstufft> I only picked the one it has because I figured it'd be less likely to break since it's just ascii

[18:57:35] <dstufft> https://github.com/verigak/progress/ it doesn't have any pictures, but it tells you the other types of bars there are

[18:59:04] <dstufft> msabramo: the new cache is pretty nice I think, it's an HTTP cache and respects HTTP, so like for PyPI on the actual package files there is a really long cache time, so for those it'll likely not need to request the file again, there's a much shorter cache for the index pages themselves, and if the cache expires but we still have the cached response around, it'll try to do a conditional get to refresh the cache instead of fetching the whole

[18:59:05] <dstufft> thing again

[19:00:12] <dstufft> I want to revamp the UI to remove all the bullshit cruft, but I haven't had a lot of time

[19:26:08] <msabramo> cool

[19:26:16] <msabramo> I'd like to clean up the UI too

[19:26:37] <msabramo> I submitted one PR earlier and I have another one coming - hopefully they're not too heavy-handed

[19:27:10] <msabramo> merging https://bitbucket.org/pypa/distlib/pull-request/18/fix-57-silence-warnings-from-exclude/diff could help quite a bit too

[19:30:46] <dstufft> um

[19:30:51] <dstufft> I don't think we use that at all

[19:33:37] <msabramo> https://github.com/pypa/pip/pull/2175

[19:33:46] <msabramo> https://github.com/pypa/pip/pull/2176

[19:48:53] <xafer> https://github.com/pypa/pip/pull/2153 which fixes https://github.com/pypa/pip/issues/2174

[20:23:50] <buck1__> dstufft: to what extent do we trust the pip test suite?

[20:23:59] <dstufft> "trust" ?

[20:24:05] <buck1__> ie: if i re-develop find_requirement from scratch, passing the tests

[20:24:15] <buck1__> can we believe it will work in the real-world?

[20:24:28] <dstufft> probably not without manual testing

[20:26:18] <buck1__> dstufft: this is what i ended up with, after giving up on refactoring find_requirement https://github.com/yelp/venv-update

[20:26:27] <buck1__> monkey-patch the hell out of pip to get the behavior i want =/

[20:26:58] <dstufft> sounds like you're following in the footsteps of all the other packaging tools

[20:27:12] <dstufft> since pretty much every packaging tool is based around hacky monkeypatching at some level :V

[20:28:27] <msabramo> was the temp directory for doing builds changed in git?

[20:28:58] <dstufft> pip 6.0 uses a random build dir when it can now

[20:29:14] <msabramo> It used to use a directory like ~/virtualenvs/pip/build/ipython and then if you aborted, you'd get the error about "pip being responsible"

[20:30:02] <msabramo> I used to get that fairly often and I never wanted pip to be responsible - I was going to fix that but I think it doesn't happen so much now because the build dir is randomized

[20:30:31] <dstufft> it shouldn't happen at all anymore unless you use --no-download or --no-install or whatever those two flags are

[20:30:38] <dstufft> those flags will be gone in pip 7

[20:31:33] <dstufft> gonna say, "I never wanted pip to be responsible" made me laugh

[20:32:32] <msabramo> :)

[20:33:04] <msabramo> I never had used for a borked build directory

[20:33:09] <msabramo> s/used/use/

[20:33:57] <msabramo> can you not do a download without an install in the new pip? or is it just different in the UI?

[20:34:13] <dstufft> --no-install and --no-download had nothing to do with that

[20:34:16] <dstufft> common misconception

[20:34:26] <dstufft> pip install --download won't install things, it'll just download it

[20:34:29] <dstufft> and that's been the cast

[20:34:46] <dstufft> those flags are for a half baked "binary distribution" before we had wheels workflow

[20:35:35] <dstufft> the way ti'd work, is you'd run ``pip install --no-install foo`` on the build server which would download and build the stuff in the temp dirs, then you'd copy those temp dirs onto the target machine and do ``pip install --no-download foo`` and it'd "resume" the install from the already built dirs

[20:35:56] <dstufft> which is why we can't use randomized build dirs with those options too, becuase they rely on having well known dir names

[20:42:09] <jezdez> dstufft: +1 for the OH

[20:42:40] <msabramo> thanks, jezdez!

[20:42:49] <jezdez> https://twitter.com/ThePyPA ;)

[20:42:58] <msabramo> ah :-)

[20:43:24] <jezdez> dstufft: qwcode: pf_moore: want access to the twitter account?

[20:43:30] <jezdez> anyone else?

[20:44:45] <qwcode> jezdez, thanks, but I don't really tweat or follow tweats. : (

[20:45:00] <jezdez> qwcode: no problem :)

[20:45:03] <msabramo> I think people are afraid of the power. 3 followers! ;-)

[20:45:13] <jezdez> yep, world. changing.

[20:45:38] <msabramo> love the idea of pypa tweeting though

[20:46:03] <msabramo> need my pypa news in 140 byte chunks

[20:47:01] <jezdez> yeah, gonna do this randomly

[20:47:10] <jezdez> sadly there is no easy way to share the account

[20:48:28] <pf_moore> jezdez: same here, I don't really use twitter much

[20:48:36] <jezdez> k :)

[20:50:19] <dstufft> I use twitter a bunch, but I never remember to use the other accounts I have access too

[20:50:31] <dstufft> so you can give me the pw if you want, but I probably won't remember to use it :V

[20:53:04] <msabramo> wonder if my OH has more meaning to pip insiders

[20:53:35] <msabramo> I just never wanted pip to not install something because I had a leftover borked build directory laying around

[20:53:49] <msabramo> but maybe my comment can be interpreted in other contexts? :)

[20:54:17] <dstufft> I thought you wanted us to just go hog wild and do whatever we wanted

[20:54:20] <dstufft> ;D

[20:58:02] <dstufft> the next version of pip will be 3.4+ only and will be written to use asyncio

[20:58:09] <dstufft> irresponsibility is cool

[20:59:15] <msabramo> nah, responsibility is good most of the time

[20:59:46] <msabramo> I'm too old to deal with shitty package management

[21:00:16] <msabramo> err, irresponsible package management

[21:01:01] <msabramo> now if pip can remain responsible but just be a little quieter doing it, I will be a happy camper

[21:01:45] <msabramo> and we're making progress there so this is a good day :)

[21:02:46] <msabramo> ugh, Travis failed for pypy on https://travis-ci.org/pypa/pip/jobs/43874853 in some bizarre way - probably not related to my PR methinks

[21:03:11] <dstufft> restarted

[21:03:59] <msabramo> oh I didn't know you could restart just one sub-job. kewl

[21:04:19] <msabramo> travis should have an auto start

[21:04:49] <dstufft> I wish travis just let the PR author restart/stop jobs

[21:05:09] <dstufft> gotta go get my daughter from the bus, be back in a bit

[21:09:22] <jezdez> dstufft: sent

[22:00:52] <dstufft> jezdez: cool

[22:01:01] <dstufft> jaraco: when do you think 8.0 will be released?

[22:02:36] <jaraco> dstufft, It's had a week or so. I guess we could do it this weekend.

[22:02:52] <dstufft> jaraco: awesome :D

[22:03:06] <dstufft> hopefully it won't break the world

[22:03:58] <dstufft> I'm sure there will be _some_ breakage sadly, but I don't think there's a way around that besides not make a change at all

[22:05:01] <buck1__> is there any race condition that could make the wheel module not found if it were installed in the previous second?

[22:05:35] <dstufft> um

[22:05:48] <dstufft> do you mean in two successive executions?

[22:06:01] <buck1__> yes

[22:06:15] <dstufft> not that i'm aware of

[22:06:40] <buck1__> dstufft: i can repro maybe 50% of the time

[22:06:41] <buck1__> http://paste.pound-python.org/show/4uLCITXTKy2g3csSQfZS/

[22:08:06] <dstufft> I've never seen anything that would cause that

[22:19:53] <xafer> any thought on https://github.com/pypa/pip/pull/2153 ?

[22:23:16] <dstufft> xafer: I'll be looking at it shortly

[22:23:39] <dstufft> I'm going to be going through the open PRs and seeing what can be landed in time for 6.0

[22:25:00] <xafer> great :)

[22:30:34] <buck1_> dstufft: i had to remove __pycache__ from site-packages

[23:33:15] <buck1_> why does pip install . start taking forever when my .tox becomes large?

[23:38:10] <buck1_> dstufft: i think the edge case is when a package is installed within a second of the creation of site-packages/__pycache__, or something v similar

[23:38:22] <buck1_> how do timestamps relate to __pycache__ ?

[23:48:20] <tomprince> buck1_: Because it copies the entire directory to a temporary place first.

[23:48:55] <buck1_> how do timestamps make things not importable though?

[23:51:32] <buck1_> tomprince: i have to touch site-packages for python to be able to find wheel, sometimes

[23:51:49] <buck1_> no other timestamps change

[23:52:12] <buck1_> this filesystem has one-second resolution, i suspect is one part of the issue

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Friday the 12th of December, 2014