pmxbot IRC Log Viewer

[00:25:18] <dstufft> agronholm: should be able to do yes

[00:25:49] <agronholm> dstufft: as I understand, after_success is ran when the current build completes successfully

[00:26:09] <dstufft> oh I missed the "onlyif the build succeeds as a whole" part

[00:26:10] <dstufft> don't think so no

[01:00:31] <agronholm> the changelog is still at 7.1.2?

[01:07:00] <dstufft> agronholm: which changelog?

[01:07:13] <agronholm> dstufft: https://pip.pypa.io/en/stable/news/

[01:07:15] <dstufft> (the location specifically)

[01:07:19] <dstufft> ah,t hat's cached in FAstly

[01:07:35] <dstufft> shows up for 8.0 for me

[01:07:52] <agronholm> where should I look then

[01:08:33] <agronholm> docs/news.rst is empty

[01:09:07] <agronholm> agh, CHANGES.txt of cours

[01:09:30] <agronholm> wow, that's an impressive list of changes

[01:09:58] <dstufft> I purged that URL

[01:09:59] <dstufft> just now

[01:10:26] <agronholm> ok, now it shows 8.0 for me

[01:10:32] <agronholm> thanks

[01:46:53] <lifeless> dstufft: ok so

[01:47:08] <lifeless> I think I should file a bug for a place to discuss this

[01:47:12] <lifeless> dstufft: and gather the screams

[01:47:25] <dstufft> sure

[01:48:09] <lifeless> dstufft: the question of how we get distros to fix their broken metadata is a good one

[01:48:29] <lifeless> dstufft: this is one reason I suggested we should move the wrapping thing out of pip

[01:48:38] <lifeless> dstufft: (so it could be invoked by distro tools directly)

[01:49:05] <lifeless> dstufft: we could however start by just filing a tonne of bugs

[01:49:11] <dstufft> the thing that force injects setuptools?

[01:49:25] <lifeless> dstufft: distros can use pip to do the install too, of course (with a --home parameter)

[01:49:35] <lifeless> dstufft: + gathers the file list

[01:49:55] <dstufft> I think Fedora is, or is planning to use pip, Debian didn't seem to thrilled about the idea

[01:53:46] <dstufft> lifeless: I need to run down the street to the pharmacy, doctor just called me in some medication

[01:54:23] <lifeless> dstufft: ciao

[01:54:42] <lifeless> dstufft: openstack has a workaround, so there's no need to panic

[01:54:59] <lifeless> dstufft: (other folk may panic, I can't comment on that :))

[01:56:44] <dstufft> lifeless: luckily, I'm gonna be looped out on medication in the near future so my level of engagement is probably not going to be massive :D

[01:57:11] <lifeless> dstufft: lucky lucky

[01:57:14] <lifeless> dstufft: you ok?

[01:57:50] <dstufft> lifeless: just some bronchitis, but the coughing is driving me crazy so they're giving me the heavy duty cough meds

[01:58:08] <lifeless> dstufft: .oO

[02:00:19] <agronholm> ouch

[03:06:17] <Ivoz> Maybe I'm out of the loop on what RTD is doing these days, or what we're doing with them

[03:06:21] <Ivoz> http://virtualenv.readthedocs.org/en/stable/changes.html

[03:06:30] <Ivoz> has 14.0 virtualenv changes, awesome

[03:06:38] <Ivoz> https://virtualenv.pypa.io/en/latest/changes.html does not

[03:07:06] <Ivoz> coincidentally I pointed the changelog in the pypi virtualenv page @ the second one

[03:10:28] <dstufft> Ivoz: try curl -XPURGE on the second url

[03:11:12] <Ivoz> Aha, it is work

[03:16:54] <Ivoz> So are these two RuntimeWarnings going to come up every pip install for me on this Windows? https://dpaste.de/BzHO

[03:17:08] <dstufft> Ivoz: *.pypa.io is behind Fastly so it's cached for a bit

[03:17:28] <Ivoz> Is this something pip should care about, or should I go shout @ Continuum

[03:17:28] <dstufft> Ivoz: dunno!

[03:17:30] <dstufft> https://github.com/pypa/pip/issues/3383

[03:17:39] <dstufft> the code is new in pip 8

[03:17:45] <dstufft> not sure whose fault it is atm

[03:17:58] <Ivoz> oh goodie someone already found it

[03:18:31] <Ivoz> Hmm, maybe this is with Python.org builds as well

[03:20:51] <Ivoz> is 'detected a distutils project' for when pip comes across something not installed by itself?

[03:25:24] <dstufft> Ivoz: it's when it's something that uses plain distutils rather than setuptools (either naturally, for via force injection)

[03:27:53] <Ivoz> but if pip is installing something it always forces setuptools if possible, right?

[03:32:24] <dstufft> Ivoz: yes

[03:33:38] <Ivoz> ok I think I found one minor bug

[03:33:48] <StevenK> Huh. https://travis-ci.org/pypa/packaging/jobs/103519351

[03:34:08] <dstufft> Oh

[03:34:09] <dstufft> Python 3.2

[03:34:23] <Ivoz> sysconfig.get_config_var('Py_DEBUG') should return None as normal, if it is not a debug build, AFAICT

[03:34:33] <Ivoz> pep425tags however treats None as error value

[03:35:07] <Ivoz> I might be wrong on 1st point. That's the value that Windows Conda Python returns anyway

[03:35:08] <StevenK> dstufft: I'm happy to push up a quick PR that bumps pep8 to 3.4 for some saneness

[03:35:23] <StevenK> And 2.7 for py2pep8 because ugh

[03:35:37] <dstufft> StevenK: sec

[03:37:26] <dstufft> I hate shells

[03:37:38] <dstufft> anyone know the right syntax for an inline conditional? :D

[03:38:03] <StevenK> foo && if thing was exit 0 || if exit 1

[03:38:20] <dstufft> Ivoz: comment on issue/file a new one and stick it in 8.0.1 milestone please

[03:38:28] <dstufft> StevenK: sorry, to test against an env var

[03:38:46] <StevenK> dstufft: If it's set, or something else?

[03:38:46] <dstufft> it's like ... [[ something something ]]

[03:39:09] <StevenK> [ -n "$VAR" ] && <thing>

[03:39:20] <dstufft> StevenK: concretely, I want to change "pip install tox" to "pip install tox virtualenv<14" when TOXENV=pep8

[03:39:56] <StevenK> [ "$TOXENV" = "pep8" ] && pip install tox virtualenv<14

[03:40:05] <dstufft> thanks :D

[03:40:18] <Ivoz> does "import sysconfig; repr(sysconfig.get_config_var('Py_DEBUG'))" give something other that None on *nix pythons?

[03:42:27] <dstufft> StevenK: https://github.com/pypa/packaging/pull/58 should fix

[03:42:46] <jimbaker> good to see pip 8.0 out there. upgrading to it on jython master works except on windows. anyway, we will bundle 7.1.2 for our next release, and look at what we need to do next

[03:43:03] <jimbaker> probably helpful if we add jython to tox.ini for future testing

[03:43:08] <dstufft> $ python -c "import sysconfig; print(repr(sysconfig.get_config_var('Py_DEBUG')))"

[03:43:09] <dstufft> 0

[03:43:24] <dstufft> jimbaker: if someone who knows how to Jython can add it to our travis config that'd be great :)

[03:43:26] <StevenK> dstufft: Are you planning to cowboy that in, since it doesn't pass :-)

[03:43:30] <dstufft> we need to get windows testing :(

[03:43:42] <dstufft> StevenK: ugh

[03:43:45] <jimbaker> dstufft, darjus probably will look at this

[03:43:45] <dstufft> I hate computers

[03:43:47] <dstufft> fyi

[03:44:00] <StevenK> dstufft: You know, you're in my signature for a quote like that

[03:44:05] <jimbaker> we do have an outstanding PR in setuptools btw for jython

[03:44:18] <jimbaker> which we are currently bundling with that fix

[03:44:44] <jimbaker> i believe you probably have updated the vendoring of our distlib change, but will check

[03:45:27] <jimbaker> dstufft, https://bitbucket.org/pypa/setuptools/pull-requests/169/remove-jythoncommandspec-as-its-not/diff

[03:46:03] <dstufft> jimbaker: cool, that doesn't touch anything we bendor in pip so that is nice when that works :)

[03:46:24] <jimbaker> dstufft, yeah, just want to get it in the next setuptools release

[03:47:04] <dstufft> jimbaker: that's a jaraco thing :) I think I techincally have commit bit through the nature of being an org admin, but I was never actually made a committer to setuptools :)

[03:47:09] <jimbaker> since stuff like installing yolk will now attempt to update to 19.4... and that will then break our patched 19.2

[03:47:37] <jimbaker> (i use yolk as a functional test of setuptools on windows)

[03:48:26] <jimbaker> dstufft, ack about ownership. anyway, we will get this converged. i think we will stick with our bundles for now, but obviously we want any user upgrades to be seamless

[03:48:33] <StevenK> Huh, no, it's broken

[03:48:35] <StevenK> The command "[ "$TOXENV" = "pep8" ] && pip install "virtualenv<14"" failed and exited with 1 during .

[03:48:36] <jimbaker> we plan to be releasing 2.7.1 real soon now

[03:48:47] <StevenK> Travis, you are a terrible thing, and I hate you.

[03:49:08] <jimbaker> so pip 8.1 and setuptools 19.5+ hopefully will be good

[03:49:26] <jimbaker> but at least 8.0 works well on unix-y systems

[03:49:39] <jimbaker> for jython mater

[03:49:40] <jimbaker> master

[03:50:41] <jimbaker> dstufft, also there is this: http://bugs.jython.org/issue2446 - so we just warning messages about lacking SNI support

[03:51:20] <jimbaker> *just get warning*

[03:52:00] <dstufft> jimbaker: that's awesome ++

[03:54:42] <jimbaker> dstufft, yeah, so we plan to fix that in 2.7.2. it should be easy, although it will require users to run java 8. just a SMOP

[03:55:46] <dstufft> jimbaker: fwiw we don't currently have testing on Windows, so Jython on Windows is at a similar state to all other pip on Windows (except that I don't think any pip cores run Jython) but hopefully we'll get that in the future

[03:57:19] <dstufft> StevenK: Ok, now https://github.com/pypa/packaging/pull/58 should work

[03:57:23] <dstufft> only took like 15 tries

[03:57:26] <dstufft> shell is the worst

[03:57:59] <jimbaker> dstufft, sounds fine. it's possible windows on pip will then see the same issue, depending on how good a job we did in terms of saying the underlying os is windows

[03:58:13] <jimbaker> the problem is seen in upgrade specifically, in an unlink of old pip

[03:58:40] <jimbaker> so hey, we might have a fix sooner than later for this :)

[03:59:18] <StevenK> dstufft: Shell is wonderful! Travis just does evil things for its logging

[03:59:54] <StevenK> Ah, a one line if.

[04:01:09] <dstufft> jimbaker: how compatible is Jython with regular pure python anyways? Is pip just (as usual) a weirdo or does it typically take knowing ahead of time you're going to be running on Jython to support it?

[04:04:42] <jimbaker> dstufft, i think we have fairly minor changes at this point

[04:04:53] <jimbaker> also your embrace of ssl has been a moving target for us

[04:05:33] <jimbaker> so we recently added SSLContext for example, which more or less is the same as the java equivalent. more or less, it took some work to make it so ;)

[04:05:45] <StevenK> dstufft: https://github.com/pypa/packaging/pull/50 is ready for you

[04:05:50] <jimbaker> next up is SNI, but that should be straightforward

[04:05:59] <Ivoz> is 3 lines if you count the semicolons!

[04:34:43] <jimbaker> dstufft, also i looked at that windows problem in more detail. although it fails with an unlink error, it looks like pip 8.0 does install on windows. so probably just a cleanup problem that is mostly harmless

[04:35:14] <jimbaker> still want to fix of course :)

[04:35:45] <dstufft> jimbaker: at some point I think we made cleanup more brute force

[04:35:52] <dstufft> not sure if that was in 7x 6x or 8x

[04:36:19] <dstufft> IIRC we basically turned a failing call to delete some temp files, into up to N calls to delete some temp files

[04:36:31] <dstufft> because when a thing fails, you just call it more times until it stops failing!

[11:02:16] <xafer> :-/ I didnt see they were on master

[12:27:17] <Ivoz> dstufft, thought of making a 7.1.3 with a check you're not on py32 before telling you a new vers is available?

[12:27:52] <dstufft> doesn't seem worth it, anyone currently on 7.1.2 would already be getting told to go to 8

[12:29:35] <Ivoz> farg that would've been a good idea

[12:29:43] <Ivoz> pip-8.0.0-py2.py33-none-any.whl

[12:31:38] <dstufft> it'd still download pip-8.0.tar.gz

[14:14:56] <xafer> dstufft: in fact --binary-only and --no-binary are (and were) not supported with pip list

[14:15:10] <dstufft> xafer: oh, was that the case?

[14:15:16] <dstufft> I was tired last night

[14:15:18] <xafer> (and of course I saw that after writing the test ^^)

[14:22:22] <dstufft> xafer: thanks for getting that fixed :)

[14:23:48] <xafer> It was my mistake in the first place :)

[14:43:40] <xafer> dstufft: I forgot a changelog for the pip list --pre issue, should I add it to the 8.1 section or will you cherrypick it in master for a 8.0.1 ?

[14:57:24] <dstufft> xafer: I can handle it, I'll probably cherry-pick or cut a release of develop with the changelog adjusted

[14:57:28] <dstufft> either way, I cant ake care of it

[19:15:36] <lifeless> dhellmann: ok, commented on the bug

[19:20:12] <dstufft> just FYI I'm purposely ignoring thinking about the case that was supposed to break (thing installed with distutils where we don't have metadata, being uninstalled either locally to a virtual environment, or without a virutal environment at play) until I sort out the cases that weren't supposed to break, so I can more cleanly seperate who is affected by which

[19:23:17] <dstufft> /cc lifeless ^ or whomever

[19:23:25] <kostco> Hey can I bug y'all to merge this guy in? https://github.com/pypa/pip/pull/3372

[19:25:06] <dstufft> kostco: Probably not right now, just because dealing with fall out from pip 8, I'll try to get it soon though

[19:26:13] <kostco> Thanks dstufft. Good luck dealing with the fallout

[19:27:13] <dstufft> https://www.youtube.com/watch?v=n9D6GNzpmkM :3

[19:34:02] <dstufft> Guess I need to spin up a VM

[19:34:31] <dstufft> testing interactions with the system doesn't work very well when I've tailored my existence to eliminate the system's influence on my Python

[19:35:08] <kostco> Fixing a vm is what drove me down the rabbit hole all the way to making a pr on pip.

[19:38:30] <lifeless> dstufft: yeah; perhaps we should have a separate bug ?

[19:38:54] <dstufft> seems reasonable

[19:42:19] <lifeless> dstufft: done

[19:42:48] <dstufft> https://caremad.io/s/DYt3b9Kw6p/ can you spot the theme of what I use my Rackspace account for?

[19:44:13] <lifeless> :)

[19:46:03] <lifeless> dstufft: ok, what can I do to help with this firedrill ?

[19:47:56] <dstufft> lifeless: I'm thinking we should just no-op attempts to upgrade/install items that in in immutable locations (specifically the standard library right now), possibly with an error if someone attempts to do something crazy like pip install argparse<wahteverversionisinthestdlib

[19:48:13] <dstufft> the only reason a dependency on "argparse" is trying to do anything is becuase of recursive --upgrade

[19:48:29] <dstufft> does that seem reasonable?

[19:52:09] <ErikRose> dstufft: Ha, nice Rackspace menu. :-)

[19:57:29] <lifeless> dstufft: I'd like to not cause installing existing packages to error

[19:57:35] <lifeless> dstufft: other than that it sounds reasonable

[20:00:33] <dstufft> lifeless: so it wouldn't break unless the dependency is essentially unsatisifiable with what is shipped in stdlib, which I think is a reasonable case to error on, because that is unsatisfiable

[20:01:38] <lifeless> dstufft: well

[20:02:41] <lifeless> dstufft: I guess I'm thinking forward to resolver time :)

[20:05:14] <dstufft> actually, those two things probably don't need to be related

[20:05:29] <dstufft> we just need to no-op uninstalling argparse &co when they are in the standard library

[20:05:42] <dstufft> we can still do the shadowed install and deal with it later

[20:06:00] <dstufft> I think that makes more sense

[20:11:40] <lifeless> dstufft: yes

[20:12:07] <lifeless> dstufft: similar to freeze_excludes

[20:12:14] <dstufft> lifeless: want to make that PR?

[20:12:19] <lifeless> on it

[20:12:43] <dstufft> Also: "pip 8.0.0 is already the 7th most used downloader" since the new stats daemon I wrote started recording data this last weekend.

[20:13:36] <lifeless> dstufft: base on develop or master?

[20:13:43] <dstufft> develop is fine

[20:14:12] <dstufft> best case I'll just cut 8.0.1 from there with an updated version, worse case I'll do the cherry-picks

[20:20:27] <lifeless> right, failing test written

[20:28:47] <lifeless> dstufft: CHANGES.txt still says 8.0.0 is unreleased :)

[20:29:14] <dstufft> https://github.com/pypa/pip/blob/develop/CHANGES.txt#L4 ?

[20:29:58] <lifeless> hmm, maybe I pulled from the wrong repo

[20:45:22] <lifeless> dstufft: in your stats thing, whats the py2.6 % for unittest2?

[20:46:28] <dstufft> lifeless: I can check, want access to the data?

[20:47:02] <lifeless> sure

[20:48:44] <dstufft> lifeless: google account?

[20:49:47] <lifeless> dstufft: my normal email

[20:50:22] <dstufft> lifeless: you should have invite

[20:50:37] <dstufft> it's all in bigquery on the long-stack-somenumber project

[20:50:40] <dstufft> sec I can get you some example queries

[20:50:55] <dstufft> https://gist.github.com/alex/4f100a9592b05e9b4d63

[20:51:22] <dstufft> just go to the google cloud console, log in, click "big query", then click on "compose query" and run a query ^

[20:51:50] <dstufft> schema is https://github.com/pypa/linehaul/blob/master/schema.json or there's a details button too that'll show you a view of it

[20:52:21] <lifeless> dstufft: I also have an account at myfirstname.lastname@gmail.com - we've used that for hangouts

[20:52:27] <lifeless> dstufft: (I got the invite)

[20:53:04] <dstufft> https://caremad.io/s/uLnIT3650Y/ here's the unittest2 data though fwiw

[20:54:12] <dstufft> I'm talking to the BigQuery team at Google about making this data available as part of their publicdata

[20:54:16] <dstufft> so anyone can query it

[20:54:30] <dstufft> still need to load the historical data in :/

[20:55:42] <lifeless> oh man

[20:55:47] <lifeless> they haven't enabled domains for bigquery

[20:55:54] <lifeless> I hate the spotty way they do that

[20:55:55] <dstufft> ah

[20:55:57] <dstufft> yea

[20:56:00] <dstufft> want your gmail then?

[20:56:12] <lifeless> yeah

[20:56:44] <lifeless> so yeah 10% still unittest2

[20:56:51] <lifeless> erm 10% still 2.6

[20:56:56] <dstufft> ok, you should have another invite

[20:57:41] <lifeless> thanks

[20:57:44] <dstufft> all data in bigquery should be able to be made public fwiw, so feel free to do whatever queries and share whatever data

[20:57:48] <lifeless> anyhow - the PR for argparse is up

[20:57:53] <lifeless> will do, thanks

[20:58:04] <lifeless> travis are reporting slowly, though apparently jobs are running ok

[20:58:10] <lifeless> (status.travis-ci.org)

[20:58:53] <dstufft> I need to get around to figuring out a more comprehensive CI for pip :/

[20:59:08] <lifeless> travis is ok IMO

[20:59:22] <lifeless> just saying, don't wait on travis to review :)

[20:59:42] <dstufft> Travis is OK, but doesn't cover Windows, and the OSX is super slow, and doens't cover _other_ versions of Linux and such

[21:00:00] <dstufft> oh I already reviewed

[21:00:07] <dstufft> I'm gonna merge as soon as travis says it's OK

[21:01:02] <lifeless> it will conflict a little with your patch

[21:01:22] <dstufft> yea, I'm gonna land mine after yours, yours has nicer stuff for the error reporting

[21:01:29] <lifeless> yours shows the fatal output on stdout that I fixed in mine (since they have in common setting uninstall_paths to nothing)

[21:01:36] <dstufft> so I'll rebase and update mine

[21:01:39] <lifeless> cool

[21:01:43] <dstufft> gotta go Alyssa from the bus stop

[21:01:48] <lifeless> ciao

[21:07:24] <lifeless> oh pep8

[21:07:26] <lifeless> I just love you

[21:29:19] <jakobdm> hey guys :) are you planning to release 8.0.1 soonish? We freeze pip in a Windows binary and I'd like to avoid the PEP425 runtime warnings (#3383) in our next release

[21:29:48] <jakobdm> +pip

[21:41:28] <tomprince> jakobdm: Yes. I suspect in the next day or so. (Although I just lurk here, so don't take that as official)

[21:48:35] <lifeless> jakobdm: asap basically, we need to gather together the major regression patches and land them, then release

[21:53:33] <lifeless> oh yay. https://github.com/pypa/pip/issues/3408

[21:57:17] <lifeless> dstufft: I'll prep a patch for ^ shortly

[21:57:22] <lifeless> erm

[21:57:53] <lifeless> already done I see

[22:03:53] <xafer> :)

[22:20:35] <xafer> lifeless: I reviewed your PR, the test seems suspicious

[22:29:39] <lifeless> xafer: try the test without the patch; it fails. try the test without the reporting tweak; it fails :)

[22:29:52] <lifeless> xafer: the tests implicitly check for status code 0 and nothing on stderr

[22:35:12] <xafer> yup, got bitten (again) by bash redirection on pip install pkg>=1.4

[22:35:23] <xafer> (vs "pkg>=1.4")

[22:39:25] <xafer> might be good to combine with dist_is_local check to avoid

[22:39:41] <xafer> "Not uninstalling argparse at /home/xfernandez/.virtualenvs/211dffcc587118e3/lib/python3.4/site-packages, is in the standard library."

[22:43:28] <lifeless> xafer: well, I wanted to emit that message - its new

[22:43:56] <lifeless> xafer: because we're going to have the argparse we installed shadowed by that, and this gives visual warning to folk that somthing is wrong

[22:44:07] <lifeless> xafer: without all the logic needed to really check it is going to be shadowed

[22:44:47] <xafer> well in this case, this path looks like the venv site-packages

[22:44:56] <xafer> not the stdlib

[22:46:16] <xafer> (in 3.4 argparse does not seem to have metadata anymore)

[22:46:30] <lifeless> dstufft: travis is green btw

[22:47:07] <lifeless> xafer: hmm, travis was green :/.

[22:47:32] <lifeless> xafer: so, it may need a little more iteration

[22:49:21] <lifeless> xafer: yeah, argparse egg info is missing in 3.4

[22:49:28] <lifeless> 'yay'

[22:51:16] <xafer> And even if my initial reasons were bad I still think you should check the pip.script output, to make sure pip did the thing you expected

[22:55:06] <xafer> But it does indeed work as a stopgap :)

[22:55:22] <lifeless> so this is messy

[22:55:31] <lifeless> when argparse is requested

[22:55:35] <lifeless> we *must* end up with argparse installed

[22:55:45] <lifeless> otherwise pkg_resources.require() will error

[22:55:58] <lifeless> installed means 'has egg info metadata'

[22:56:03] <lifeless> not 'can be imported'

[22:56:16] <lifeless> python3.4 by not having the metadata, means we actually have to install argparse there.

[22:56:56] <lifeless> and we can't ignore it on uninstall on 3.4+, because then we're not uninstalling something we should

[22:57:08] <lifeless> I'm questioning my life choices right now

[22:59:32] <xafer> ^^

[23:00:07] <xafer> I think your current solution should be good enough for a 8.0.1 and we'll have time to find a better one for 8.1

[23:00:46] <xafer> Anyway, my choice is to go to bed now, looking forward for tomorrow's pip version ^^

[23:01:54] <lifeless> xafer: I thought project_name came out of pkg_resources

[23:02:05] <lifeless> xafer: self.satisfied_by = pkg_resources.get_distribution(self.req)

[23:02:18] <lifeless> xafer: and pkg_resources does its normalisation there

[23:04:40] <lifeless> xafer: oh, headdesk. I see, it doth now.

[23:10:28] <lifeless> xafer: changed it to .key

[23:14:09] <dstufft> Okay

[23:14:13] <dstufft> I have returned

[23:23:18] <transit> Any tips for getting a pip merge request looked at?

[23:45:02] <dstufft> lifeless: Ok

[23:45:06] <dstufft> so here's my plan

[23:45:26] <lifeless> dstufft: hai

[23:45:33] <lifeless> dstufft: so, I'm thinking checking for sys.purelib

[23:45:43] <lifeless> dstufft: rather than stdlib_pkgs

[23:46:41] <dstufft> Once we get the things merged that removes the accidental spurious failures on stdlib and system-site-packages so that they are classified correctly, I'm going to go ahead and roll back the error to a warning.

[23:48:05] <lifeless> dstufft: \o/

[23:48:43] <dstufft> I'm not super happy about it since it's going to block other improvements I was hoping to make, but I'm going to go bother Debian and... I guess Fedora? to get them to force setuptools on everything.

[23:49:36] <lifeless> yeah, I get tht

[23:49:40] <lifeless> what improvements are blocked on that ?

[23:51:29] <dstufft> lifeless: Starting to refuse to shit all over files that are already existing on the filesystem willy-nilly and checking that we're not trampling over existing files

[23:51:56] <dstufft> which will make things like this https://github.com/pypa/pip/issues/3309 obvious errors

[23:52:01] <lifeless> dstufft: we can get some of that regardless

[23:52:26] <dstufft> well we can't because upgrading a distutils distribution relies on the fact we trample over files willy nilly

[23:52:28] <dstufft> it's the only reason it works

[23:52:46] <lifeless> dstufft: i know

[23:52:52] <lifeless> dstufft: so, some strategies...

[23:53:11] <lifeless> dstufft: if no distutils distributions in the reqset, enable checking

[23:53:29] <lifeless> dstufft: enable checking, but warn rather than fatal if distutils in the set

[23:54:12] <lifeless> dstufft: enable checking, and degrade to warnings replacements of paths with a component matching the name

[23:54:34] <lifeless> dstufft: like, it is more complex, but I think we can get quite a lot of that benefit fairly early

[23:55:54] <dstufft> yea, we can get some of the way there, not the whole way there.

[23:56:03] <dstufft> https://github.com/pypa/pip/pull/3406 is this ready to land now, or are you still poking at it

[23:56:38] <lifeless> dstufft: well, lets talk for a second

[23:56:47] <lifeless> dstufft: on 2.7 3406 seems solid

[23:56:58] <lifeless> dstufft: on 3.4, at least on ubuntu, there is no egg-info metadata for argparse

[23:57:34] <lifeless> dstufft: so, pip install argparse will install the argparse distribution. And we have to have it do that, otherwise pkg_resources.require will error on argparse missing and break folk

[23:57:53] <lifeless> / trigger easy-install if we're not installing a wheel

[23:58:21] <lifeless> dstufft: so on 3.4, we'll actually have argparse installed, and then when the next upgrade to it happens, this code will mean we don't uninstall the old version properly.

[23:58:41] <lifeless> dstufft: I've just been pondering how to properly detect 'argparse from the stdlib is what we detected for conflicts_with'

[23:59:27] <Ivoz> has pkg_resources since fixed not being able to see argparse is 'installed'?

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Wednesday the 20th of January, 2016