Log file Viewer

[00:17:15] <msabramo> well if not a pycon sprint, maybe just a remote sprint whenever on slack or irc

[01:03:29] <msabramo> dstufft: What do you think of https://github.com/pypa/pip/pull/2183 ?

[01:05:24] <dstufft> msabramo: I'm thinking about it some, I'm bouncing between not having a problem with it, and thinking that maybe saying the filename at all is more than we need :V

[01:06:12] <msabramo> dstufft: I like seeing the URL because I like to verify that I'm installing from my internal devpi at work

[01:06:43] <Alex_Gaynor> Personally I think showing the URL is better than the filename, but maybe showing only the package name (and version?) would be best

[01:06:49] <msabramo> if the config is wrong and it's downloading from PyPI, then things are going to fail when it gets to our internal stuff

[01:07:28] <dstufft> Alex_Gaynor: right, that's sort of my opinion

[01:07:39] <msabramo> it seems weird to say "Downloading" but then not show where it's downloading from

[01:07:41] <dstufft> url is better than filename, but that maybe just package name and version is best

[01:08:12] <Alex_Gaynor> "Download Django==1.7.2" seems like a solid output

[01:08:20] <msabramo> and believe me, I'm a fan of making pip quiet :)

[01:09:05] <dstufft> msabramo: I plan to revamp the index support for pip at some point, which will likely include "naming" the indexes

[01:09:12] <msabramo> ugh you guys are going to make me create an option for it :)

[01:09:24] <dstufft> so maybe the real answer is

[01:09:54] <dstufft> "Downloading Django 1.7.2" for now, and then when the revamped multi index support happens, change it to "Downloading Django 1.7.2 from <Human Name of Repo"

[01:10:34] <msabramo> that endpoint sounds nice

[01:10:40] <dstufft> msabramo: I'm -1 on an option for it, this isn't something users really need to configure, adding an option is just an excuse not to make a decision

[01:12:18] <dstufft> there was a great post on the internet about that...

[01:12:21] <dstufft> wonder if I can find it again

[01:12:32] <Alex_Gaynor> dstufft: the one by gus?

[01:12:41] <dstufft> Alex_Gaynor: might be? Not sure who wrote it

[01:12:43] <Alex_Gaynor> dstufft: or the one by serious pony

[01:12:51] <Alex_Gaynor> dstufft: "Your app is making me fat"?

[01:12:57] <dstufft> it was a crappy design web page

[01:13:02] <dstufft> the page it was on sucked*

[01:13:05] <dstufft> like the design

[01:13:09] <msabramo> except it should be URL for now and then "Downloading Django 1.7.2 from <Human Name of Repo" :-)

[01:13:15] <Alex_Gaynor> http://seriouspony.com/blog/2013/7/24/your-app-makes-me-fat is pretty good

[01:14:09] <msabramo> dstufft: not sure if you saw I had some PRs for pypa/readme - https://github.com/pypa/readme

[01:14:47] <dstufft> msabramo: Downloading Django 1.7.2 from https://pypi.python.org/simple/ would be OK, possibly with a special case right now to turn the default index into "PyPI"

[01:15:11] <msabramo> dstufft: I was just thinking something similar

[01:15:36] <msabramo> maybe just display the hostname — e.g.: pypi.python.org or possibly detect that and just show PyPI

[01:15:47] <Alex_Gaynor> maybe even from the "from PyPI" when it's teh default index?

[01:16:06] <msabramo> so "PyPI" for PyPI and "https://devpi.corp.mycompany.com" when it's not

[01:16:38] <tomprince> I'd want the full URL to the base, if it isn't pypi, if it is showing anything.

[01:16:48] <tomprince> (In case I have multiple indeces on the same server.

[01:18:15] <dstufft> yea

[01:18:19] <dstufft> I agree with tomprince on that

[01:18:49] <dstufft> also I think that we could probably just omit the "from .." all together if it's PyPI, or be "from PyPI"

[01:18:53] <dstufft> either way

[01:19:07] <dstufft> msabramo: bonus points if you fix https://github.com/pypa/pip/issues/376 too if it's nearby

[01:20:57] <dstufft> Alex_Gaynor: your app makes me fat is good

[01:23:40] <dstufft> http://ometer.com/free-software-ui.html

[01:23:43] <dstufft> that's the one I was thinking of

[01:26:42] <dstufft> (Specifically the "The Question of Preferences" part)

[01:26:59] <dstufft> "A traditional free software application is configurable so that it has the union of all features anyone's ever seen in any equivalent application on any other historical platform. Or even configurable to be the union of all applications that anyone's ever seen on any historical platform (Emacs *cough*). "

[01:28:09] <dstufft> "The problem is that the more generic and infinitely flexible your UI is, the more similar it is to a programming language. Lisp is not a good user interface. "

[01:28:10] <dstufft> lol

[01:28:24] <Alex_Gaynor> lisp isn't even a good programmin glanguage

[01:28:25] <Alex_Gaynor> lol

[01:29:21] <dstufft> "One of the more amusing functions in GNU Emacs is "menu-bar-enable-clipboard." Now that KDE is fixed, Emacs is basically the last remaining X application that insists on having cut and paste that doesn't work correctly. So they have this function "menu-bar-enable-clipboard" which basically means "please make my cut and paste work correctly." Why is this an option?"

[01:31:16] <dstufft> lol

[01:31:17] <dstufft> "Reading dozens of GNOME and Red Hat bugs per day, I find that users ask for a preference by default. If a user is using my app FooBar and they come to something they think is stupid - say the app deletes all their email - it's extremely common that they'll file a bug saying "there should be an option to disable eating all my email" instead of one saying "your craptastic junk-heap of an app ate my email." People just assume that FooBar was

[01:31:18] <dstufft> designed to eat your email, and humbly ask that you let them turn off this feature they don't like. "

[01:31:39] <msabramo> (msabramo deletes his "make-pip-work-incorrectly" branch)

[01:32:54] <dstufft> msabramo: aren't all the branches the "make it work incorrectly" branch? :D

[01:33:12] <msabramo> a lot are I suppose

[01:33:37] <msabramo> pip install —work-incorrectly was going to take it to a whole 'nother level

[01:58:46] <dstufft> ok, I've did my periodic go through and skim every issue and see if we can close things

[02:41:48] <pmxbot> jaraco pushed 4 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[02:41:48] <pmxbot> Restore iterating over Version objects for compat with buildout

[02:41:48] <pmxbot> Merge pull request #16 from dstufft/fix-buildout

[02:41:48] <pmxbot> Restore iterating over Version objects for compat with buildout

[02:41:48] <pmxbot> Update changelog

[02:44:07] <pmxbot> jaraco pushed 3 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[02:44:07] <pmxbot> Bumped to 8.0.1 in preparation for next release.

[02:44:07] <pmxbot> Added tag 8.0.1 for changeset d62bf4e407b3

[02:44:07] <pmxbot> Bumped to 8.0.2 in preparation for next release.

[02:45:45] <pmxbot> jaraco pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :

[02:45:45] <pmxbot> Merge with 8.0.1

[08:11:21] <msabramo> dstufft: see PRs #2183 and #2185 when you get a chance

[08:37:21] <msabramo> I'm confused by this message: "DEPRECATION: One or more of your dependencies required using a deprecated fallback to looking at /simple/ to discover it's real name. It is suggested to upgrade your index to support normalized names as the name in /simple/{name}."

[08:37:42] <msabramo> I don't quite get what it's trying to tell me

[08:37:53] <Alex_Gaynor> What's your index?

[08:38:02] <msabramo> furthermore, it seems strange that I would get that when it fails to find the package on PyPI

[08:38:13] <Alex_Gaynor> that sounds like a bug if it's pypi

[08:38:21] <msabramo> I would think (hope) that PyPI supports the thing it's talking about

[08:38:41] <msabramo> yeah I thought it was probably a bug too

[08:39:04] <dstufft> is the thing you're installing on pypi?

[08:39:08] <msabramo> my thought was that it should not output this unless it ultimately finds a package to install

[08:39:12] <msabramo> dstufft: nope

[08:39:26] <msabramo> pip install --no-cache-dir --ignore-installed thispackagedoesntexist

[08:39:52] <msabramo> pip install thispackagedoesntexist

[08:40:30] <msabramo> I don't think I have to power to upgrade the index I'm using (PyPI)

[08:40:43] <msabramo> unless I'm not using PyPI

[08:42:47] <msabramo> ok pretty sure I'm using PyPI

[08:42:49] <msabramo> DEPRECATION: One or more of your dependencies required using a deprecated fallback to looking at /simple/ to discover it's real name. It is suggested to upgrade your index (https://pypi.python.org/simple/thispackagedoesntexist/) to support normalized names as the name in /simple/{name}.

[08:43:10] <msabramo> the value in parentheses is main_index_url, which I hacked in there

[08:43:46] <msabramo> which brings up the point of should this warning be displaying the index

[08:44:18] <msabramo> as well as should this warning not be appearing at all in this particular case

[08:46:46] <msabramo> "One or more" seems strange too - since it knows the requirement it's trying to install

[08:47:08] <msabramo> "it's" is wrong too :)

[08:47:26] <dstufft> right

[08:47:29] <dstufft> the reason it's doing that is

[08:47:35] <dstufft> because we do this

[08:47:44] <dstufft> HTTP GET /simple/<name you typed in>/

[08:47:57] <dstufft> and if that doesn't work, then it does HTTP GET /simple/

[08:47:59] <dstufft> (doesn't work == 404)

[08:48:19] <dstufft> and the warning triggers when it does the fall back to /simple/

[08:48:41] <msabramo> yeah

[08:49:00] <msabramo> thing is it doesn't find it at /simple/ either so it's weird to print that

[08:49:03] <dstufft> it's annoying to differentiate between falling back to /simple/ and finding the value, and falling back to /simple/ and not finding it

[08:49:23] <msabramo> yeah, a little

[08:49:32] <msabramo> would have to set a flag and then check it later on

[08:50:09] <msabramo> or maybe add a callback to execute later on if we want to be all callbacky

[08:56:04] <msabramo> ok, I created https://github.com/pypa/pip/pull/2186 as a very simplistic way to prevent the common case with PyPI

[16:24:08] <msabramo> https://github.com/pypa/pip/pull/2186

[20:19:11] <msabramo> @dstufft, @Alex_Gaynor, @tomprince: From our discussion last night - https://github.com/pypa/pip/pull/2183

[22:31:37] <pmxbot> jaraco pushed 4 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[22:31:37] <pmxbot> Add more compatability shims to SetuptoolsVersion

[22:31:37] <pmxbot> Merge pull request #17 from dstufft/fix-buildout-again

[22:31:37] <pmxbot> Add more compatability shims to SetuptoolsVersion

[22:31:37] <pmxbot> Update changelog

[22:32:47] <pmxbot> jaraco pushed 2 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[22:32:47] <pmxbot> Added tag 8.0.2 for changeset 1c03d512e39d

[22:32:47] <pmxbot> Bumped to 8.0.3 in preparation for next release.

[22:33:36] <pmxbot> jaraco pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :

[22:33:36] <pmxbot> Merge with 8.0.2