pmxbot IRC Log Viewer

[00:12:01] <qwcode> lifeless, ^

[00:13:52] <lifeless> qwcode: thats in 7.0x?

[00:14:17] <qwcode> yea

[00:14:23] <lifeless> looked - commented

[00:14:35] <lifeless> the guarding if block needs to consult the cache too

[00:15:20] <qwcode> you wrote that part right?

[00:15:29] <lifeless> yah

[00:15:35] <lifeless> its all my failt

[00:15:36] <lifeless> fault

[00:15:47] <qwcode> I love casting my blame. makes my day...

[00:15:51] <qwcode> just kidding

[00:17:05] <lifeless> should be a simple patch, I'm just burning throug some test failures here

[00:17:14] <lifeless> but if you want to put up a patch I can eyeball for you easily

[00:18:34] <qwcode> lifeless, --no-binary ignores wheels on pypi and also won't build wheels?

[00:18:49] <lifeless> and won't try to use previously cached wheels

[00:18:52] <lifeless> IIRC

[00:19:01] <lifeless> that was so two weeks ago

[00:19:20] <qwcode> thanks

[00:19:58] <lifeless> so

[00:20:01] <lifeless> a bunch of my test fallout

[00:20:12] <lifeless> is a change in output from INITools to initools

[00:20:19] <lifeless> that is - the canonical name is getting used everywhere

[00:20:58] <lifeless> does that matter, is it good, or is it bad and I should put a mapping layer in place to map things back to the first variant we encountered?

[00:21:58] <qwcode> is there any reason for someone to use --no-cache-dir in relationship to wheels? i.e. any reason to use that beyond just using --no-binary if the goals is not use wheels?

[00:22:40] <lifeless> folk should use --no-cache-dir if they are masochistic

[00:22:51] <lifeless> if they think they have a corrupt cache, use --cache-dir=uniquevalue

[00:23:01] <dstufft> I use --no-cache-dir sometimes

[00:23:04] <lifeless> --no-binary should be used to control wheels or not wheels

[00:23:10] <lifeless> dstufft: checking it works?

[00:23:19] <dstufft> almost always to test pip downloading something where I want it to skip my cache

[00:23:27] <dstufft> because someone goes "downloading X is broken"

[00:23:38] <lifeless> dstufft: yeah, but not a common case for users :)

[00:23:38] <dstufft> I can't think of a time I used it beyond that :V

[00:23:45] <lifeless> anyhow the history here

[00:23:59] <lifeless> is that the first approximation to a blacklist was to say 'disable the cache'

[00:24:08] <lifeless> then I wrote the fine grained black/whitelist

[00:24:16] <lifeless> and ripped out the cache guard

[00:24:25] <lifeless> but the cache guard was actually still functional. OOPS.

[00:24:30] <dstufft> lifeless: also, it's totally fine to talk about this stuff

[00:24:39] <lifeless> cool

[00:25:02] <lifeless> hmmm, download is still broken in my branch; thats ok - I need to write the 'and now copy out the things we selected' loop.

[00:25:11] <lifeless> or perhaps move them out.

[00:25:33] <lifeless> I'll come back to that

[00:27:24] <lifeless> dstufft: thoughts on the canonical name vs first-encountered-variant thing

[00:27:25] <lifeless> ?

[00:27:47] <dstufft> um

[00:28:11] <dstufft> I don't personally care which way we do it. On PyPI I try to keep the "display" name being whatever the user entered, but I'm not really that worried about it either way?

[00:28:13] <lifeless> personally since Initools == iniToolS == initools == InItOoLs

[00:28:30] <lifeless> ok, well its less code to normalise once

[00:28:37] <lifeless> so, Imma do it that way :)

[00:29:30] <lifeless> dstufft: don't know if you noticed, but something went south on your packaging vendor update

[00:29:58] <dstufft> lifeless: yea I saw, I had to run out to take Alyssa to some stuff, jsut got back

[00:30:12] <dstufft> catching up on stuff now

[00:31:15] <lifeless> cool

[00:35:10] <lifeless> hah

[00:35:13] <lifeless> I think test_respect_order_in_requirements_file can die

[00:36:42] <qwcode> lifeless, with autobuilding, --no-clean leaves the wheel src, not the sdist src... did that come up in discussion?

[00:36:53] <lifeless> qwcode: no

[00:37:12] <lifeless> whats --no-clean for?

[00:37:19] <dstufft> don't clean the build directory

[00:37:21] <qwcode> lifeless, not sure it's a problem, just threw me when I saw that

[00:37:34] <lifeless> dstufft: thats what it does. What is that /for/

[00:38:00] <dstufft> lifeless: debugging mostly

[00:38:35] <dstufft> I don't personally have any sentimental attachment to it

[00:38:40] <lifeless> k

[00:38:44] <lifeless> I have preserved it in this branch

[00:38:49] <lifeless> but it looks rather different

[00:38:59] <lifeless> since - you migt have 100 different initools there

[00:39:02] <dstufft> I've never used it, but I know that some folks have for some sort of debuging things

[00:39:09] <lifeless> and I got rid of the rename-to-real-name dance

[00:39:27] <lifeless> I can possibly reinstate that now that I have a semblance of order in my code

[00:41:32] <dstufft> lol

[00:41:34] <dstufft> I think

[00:41:42] <dstufft> that the reason pip's tests are failing in my branch

[00:41:52] <dstufft> is because pip search is barfing on something someone uploaded to PyPI

[00:41:58] <lifeless> \o/

[00:42:13] <lifeless> We CANT have nice things

[00:44:48] <qwcode> "build directory" historically was the src... so this does change that for installing from sdist.... but not sure if the few people using it will notice it or not, or care...

[00:48:56] <qwcode> might be worth a "compatibility" changelog entry

[00:50:59] <dstufft> might be worth getting rid of too

[00:51:40] <qwcode> : )

[00:53:10] <dstufft> I like killing options

[00:53:15] <dstufft> less options == better

[01:00:45] <lifeless> bbiaw, gym class

[02:17:15] <lifeless> back

[02:38:41] <lifeless> dstufft: so some of these tests are IMO wrong.

[02:38:47] <lifeless> dstufft: like this one - test_install_collected_dependancies_first

[02:39:03] <lifeless> dstufft: it checks that we install paramiko before its dependencies.

[02:39:11] <lifeless> dstufft: but, since my topo branch we don't.

[02:39:23] <lifeless> dstufft: I don't know how it even passes in master :)

[02:40:04] <lifeless> s/master/develop/

[02:47:12] <lifeless> lib/python2.7/site-packages/version-pkg.egg-link

[02:47:28] <lifeless> venv/lib/python2.7/site-packages/version-subpkg.egg-link

[02:47:37] <lifeless> oh, interesting

[02:47:40] <lifeless> subpkg vs pkg

[02:50:41] <lifeless> qwcode: so build dir in 6.1.1/7 is still the unpacked archive dir; for cached wheels thats the unpacked archive of the wheel, for native wheels same, for sdists, same.

[02:50:48] <lifeless> for editables its in src/$name

[02:50:59] <lifeless> for others its in pip-build-$temp/name

[02:51:11] <lifeless> in my resolve branch name for non-editables is no longer unique

[02:51:20] <lifeless> so its in pip-build-$temp/$temp

[02:51:24] <lifeless> but otherwise the same

[03:42:10] <lifeless> dstufft: I thought you removed the distribute compat hack

[03:42:22] <lifeless> dstufft: is test_from_distribute_6_to_setuptools_70 not part of that?

[04:14:52] <qwcode> lifeless, not sure what your point is, but things changed for sdists... "pip install --no-clean -peppercorn" (with no cache) leaves a build dir with the wheel contents. peppercorn is an sdist on pypi. previously, you woud have had the sdist src

[04:15:27] <lifeless> qwcode: sure, but pip install --no-clean setuptools would always have given you a wheel on disk

[04:15:54] <lifeless> qwcode: if the wheel build step fails, you'll be left with the sdist contents for peppercorn

[04:17:15] <qwcode> but it's a change... and may be noticed by these "debug users" or whoever they are that is using this flag. just saying

[04:17:22] <lifeless> ok, potentially

[04:17:43] <lifeless> qwcode: personally I'd consider this in the undefined area of innards

[04:17:52] <qwcode> I noticed it debugding "--no-clean" for that PR that was submitted

[04:17:52] <lifeless> qwcode: and not part of the user model

[04:18:01] <lifeless> qwcode: which PR?

[04:19:28] <qwcode> https://github.com/pypa/pip/pull/2689

[04:23:44] <lifeless> ah

[04:23:58] <lifeless> so I do some stuff around this in my resolve work too

[04:24:16] <lifeless> I think I removed the per-req deletion code and let the container deletion manage it

[04:25:49] <lifeless> qwcode: anyhow, I don't really know or have a view on what it should do

[04:26:15] <lifeless> qwcode: happy to make it do something defined, but equally - and I'd advocate a bit for this - treat it as entirely internal facility.

[04:26:35] <lifeless> (Where its behaviour is subject to change w/o notice)

[04:27:38] <qwcode> I'm not sure. I'm inclined to add stuff like this to release notes, but I'm pretty persnickety...

[04:27:58] <lifeless> is there a nota bene section

[04:28:15] <lifeless> right, --force-reinstall fixed

[04:28:33] <lifeless> closing in on a green test run

[04:29:01] <qwcode> wondering if this change affects the PreviousBuildDirError code... which looks for "setup.py" in the source dir. i'd have to look closer.

[04:29:16] <lifeless> it does

[04:29:18] <lifeless> well

[04:29:23] <lifeless> here's the interactions

[04:29:28] <lifeless> if you don't specify a build dir

[04:29:29] <lifeless> its random

[04:29:32] <lifeless> so no interaction

[04:29:44] <lifeless> if you do, no-clean means you have to manually clean out the entire thing before your next run

[04:30:30] <lifeless> oh wow

[04:30:37] <lifeless> we *test* that something totally broken is done.

[04:30:40] <lifeless> I don't even.

[04:31:43] <qwcode> I'm never surprised anymore about what's in our tests...

[04:33:49] <lifeless> link in https://twitter.com/rbtcollins/status/598706867473256448

[04:34:56] <lifeless> and our help is wrong

[04:35:00] <lifeless> we claim ' -I, --ignore-installed Ignore the installed packages (reinstalling instead).

[04:35:05] <lifeless> thats not a reinstall

[04:35:08] <lifeless> its a munge

[04:36:50] <qwcode> I did "pip install --no-clean --build=/tmp/build peppercorn" twice... would have expected PreviousBuildDirError.. but no?

[04:37:01] <lifeless> with that patch yes

[04:37:10] <qwcode> patch?

[04:37:11] <lifeless> without it because we delete each req's files, no

[04:37:17] <lifeless> the PR tou linked

[04:37:21] <lifeless> you linked - 2689

[04:37:24] <qwcode> just using v7

[04:37:41] <lifeless> so v7 like v6 deletes each install_req's files separate to 'cleaning' the build dir

[04:38:02] <lifeless> I can dig up the code path if you like, but from my quick glance at the patch its disabling that

[04:38:16] <qwcode> I don't care about the patch right now

[04:38:37] <qwcode> just trying to understand when/if PreviousBuildDirError would ever be thrown?

[04:38:43] <lifeless> ok

[04:38:55] <lifeless> so right now I believe the conditions are:

[04:38:56] <qwcode> maybe that should be gone now

[04:38:59] <lifeless> - explicit build dir

[04:39:05] <lifeless> - build fails on dep X

[04:39:13] <lifeless> -> repeat and get PBDE

[04:39:20] <lifeless> qwcode: I deleted it in my resolver branch

[04:39:35] <qwcode> ok, nuff said then. I won't worry about

[04:42:45] <lifeless> man, I feel dirty ('fixing' ignore-installed

[04:44:06] <qwcode> so your talk is going to be part 1: pip before I came... the horror.... part2: the new glory of topo sort, static metadata and backtracking.... is that the gist?

[04:44:17] <qwcode> : )

[05:05:15] <qwcode> lifeless, not sure people are going to understand what " this kindof exploded." is referring to? I don't? you mean PR was harder than you thought?

[05:06:16] <lifeless> something like. I might not claim glory now though... maybe gory.

[05:06:28] <lifeless> qwcode: exploded... hmm rings a bell. Context?

[05:07:01] <qwcode> what you just wrote in #988

[05:07:19] <lifeless> heh, ETIRED.

[05:08:01] <lifeless> try that

[05:09:44] <qwcode> ok, got it. anyway, logging off. hope your talk idea makes it. you have done a HUGE!! amount for pip.

[05:44:36] <lifeless> dstufft: you'll want https://github.com/pypa/pip/pull/2782 in for the 7.0 release

[07:20:09] <lifeless> ulp, onto 'no deps'.

[14:40:35] <agronholm> dstufft: I'm trying to run the tests on pip but I have no clue which version of html5lib it has vendored, and there's no documentation saying what it is

[14:40:51] <dstufft> agronholm: pip/_vendor/vendor.txt

[14:41:06] <agronholm> ahh

[14:41:22] <agronholm> have you updated html5lib yet?

[14:41:58] <dstufft> it's 1.0b5 I think

[14:41:59] <dstufft> IIRC

[14:42:28] <agronholm> vendor.txt says html5lib==1.0b1

[14:42:45] <agronholm> and this is from the develop branch

[14:43:19] <dstufft> https://github.com/pypa/pip/blob/develop/pip/_vendor/vendor.txt#L2 ?

[14:43:26] <sigmavirus24> agronholm: it looks like html5lib/__init__.py has a __version__ specifier

[14:43:41] <sigmavirus24> agronholm: do you have an old checkout?

[14:43:58] <sigmavirus24> agronholm: https://github.com/pypa/pip/blob/develop/pip/_vendor/html5lib/__init__.py#L23

[14:44:05] <agronholm> seems like I had a remote pointing to the wrong repo, sorry

[14:44:12] <sigmavirus24> agronholm: no worries :)

[14:44:51] <agronholm> ok, much better :)

[14:45:09] <sigmavirus24> :D

[14:47:39] <agronholm> agh, "RuntimeError: maximum recursion depth exceeded (Java StackOverflowError)"

[14:47:48] <agronholm> trying to install dev requirements...meh

[14:49:09] <agronholm> trying to install pytest manually: OSError: [Errno 20] Not a directory: u'/home/alex/.cache/pip/wheels/pytest-2.7.0.tar.gz'

[14:50:18] <agronholm> ok, shouldn't have run that in pip's directory

[18:47:34] <lifeless> dstufft: so, down to just the download tests breaking AFAICT locally. ship it.

[21:36:01] <lifeless> dstufft: reminder: 2716

[21:36:09] <lifeless> dstufft: I have to prep for summit

[21:36:30] <lifeless> dstufft: but after that I hope to finish getting a green test run today, and then start really looking at the aesthetics of the code shape

[21:36:49] <dstufft> lifeless: ok, right this minute PyPI is sad so I'm fixing that

[21:37:01] <lifeless> k

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Thursday the 14th of May, 2015