Log file Viewer
#pypa logs for Sunday the 30th of November, 2014
[18:35:36] <dstufft> tdsmith: we use that file for installing Wheels (and setuptools will use that file for installing sdists)
[18:39:32] <tdsmith> Okay, thanks. We're looking at whether it makes sense to use ensurepip to bundle pip with Homebrew's python instead of downloading setuptools and pip from pypi and running setup.py, which is what we do now
[18:40:05] <tdsmith> thinking ensurepip doesn't really help us but I don't think we're the target audience anyway
[18:41:21] <Alex_Gaynor> Err, it seem slike it makes sense for homebrew to use ensurepip instead of basically doing the same thing manually?
[18:41:39] <dstufft> well homebrew will be able to use newer versions of pip and setuptools easier if they do it themselves
[18:42:24] <tdsmith> i thought I agreed Alex_Gaynor but if ensurepip is susceptible to user config that's bad, there's no way to just make ensurepip always install pip no matter what, and yeah it'd be nice if we can bundle the freshest versions
[18:42:27] <dstufft> I don't think it makes a whole lot of idfference either way though, ensurepip doesn't touch the internet so it'll only install the version bundled with that version of Python
[18:43:00] <dstufft> I don't think there's a way you can install pip/setuptools where it won't take ~/.pydistutils.cfg into account
[18:44:15] <dstufft> We wern't sure if it made sense to ignore user config in ~/.pydistutils.cfg or not though
[18:45:00] <tdsmith> Homebrew needs it because we actually run the code on the user's computer instead of just packaging the result but maybe nobody else cares
[18:45:24] <dstufft> well that code gets run on the OSX installers and the Windows installers on the end users machines too
[18:46:25] <dstufft> tdsmith: if you could comment on that issue about your use case? Right now our --isolated mode in the develop branch continues to use ~/.pydistutils.cfg
[18:47:02] <dstufft> but if setuptools supports a --no-user-cfg (which I wasn't aware of), that makes it a stronger argument that --isolated should ignore ~/.pydistutils.cfg just like it ignores ~/.pip/pipc.onf
[18:48:19] <dstufft> that would mean homebrew could do something like <downloads the latest wheels into a temp dir>, python -m ensurepip --wheel-dir <tmpdir>
[18:50:42] <tdsmith> running setup.py instead of staging a wheel isn't a big hassle for us I don't think; if ensurepip yanks setuptools we'll have to setup.py setuptools anyway
[18:51:37] <dstufft> tdsmith: well installing from a Wheel is somewhat better, invoking the ``pip`` command doesn't invoke the pkg_resources machinery in that case
[18:55:28] <dstufft> tdsmith: the tl;dr is that whateer makes sense for homebrew is fine, but if there's stuff that pip or ensurepip can do to make things easier for y'all just tell us :D
[18:56:44] <dstufft> I don't use homebrew python anymore, so I'm a little out the loop for what it does
[18:57:15] <tdsmith> hopefully you don't have to think about homebrew python; if you hear it's doing stupid things yell at me :p
[18:59:02] <dstufft> tdsmith: yea? in pip 6.0 that turns into a greater than equals instead of just an equals
[19:00:22] <tdsmith> Okay, nice, I think. I noticed a lot of wheels with 10.9 in them, learned it was because of us, and then wondered how that was going to interact with everyone moving to 10.10
[19:01:24] <dstufft> but as long as OSX is right about the SDK versions being "and later", a wheel made on Python.org will work on homebtew
[19:03:29] <dstufft> if homebrew on 10.10 creates wheels with the 10.10 SDK that won't work on a homebrew on 10.9 that is using the 10.9 SDK
[19:03:45] <dstufft> it might be reasonable for homebrew to compile against the 10.6 SDK like Python.org does, I don't know
[19:04:16] <dstufft> I don't actually know what the difference is between the 10.6 and the 10.9 or the 10.10 SDK is, and what you lose by compiling against the older one
[19:04:51] <tdsmith> selfishly, I'm mostly worried about whether Homebrew users will be able to take advantage of wheels
[19:05:13] <tdsmith> I think we set the deployment target to the current OS version to fix some problem with building with clang on Lion or something
[19:05:22] <dstufft> of course a 10.10 homebrew user would create wheels that a 10.9 homebrew user can't use
[19:06:05] <tdsmith> yeah I should probably worry about package authors using Homebrew Python eventually
[19:06:39] <dstufft> (I don't know what the system python does in this regard, it's possible they compile system python using the latest SDK so in that case homebrew isn't adding any more to the matrix)
[19:08:06] <dstufft> so I guess for people who want to create a wheel that works for as many pythons as possible, they should probably build them with Python.org installers
[19:08:49] <dstufft> which should work (from what i'm told! and it's how pip 6.0 works) on Python.org installers, system python, homebrew, pyenv, etc
[22:07:37] <dstufft> tdsmith: I commented on your issue, it occurred too me that Homebrew can install with ensurepip and then just do ``pip install --upgrade pip setuptools`` after that
[22:08:02] <dstufft> which will make sure you have both pip and setuptools installed with the latest versions on PyPI without having to manage any downloading yourself
[22:10:00] <dstufft> tdsmith: heh, well fair enough I suppose ;) though it means you won't get advantage of new improvements to the PyPI APIs and security improvements automatically
[22:19:28] <dstufft> tdsmith: well I'm sure I could invent a scenario in my head where it happens, but I wouldn't expect any of those scenarios to actually happen
[22:22:05] <dstufft> tdsmith: I do want to emphasize, do what makes sense :) I'd love it if ensurepip and/or pip is what makes sense but if it's not I won't feel bad :D
[22:59:04] <tdsmith> dstufft: do you want spelling tweaks on the Github PEP and which workflow should I use to submit them? ;)