pmxbot IRC Log Viewer

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

[01:04:33] <pmxbot> Fix buids -> builds

[13:36:16] <ronny> hi

[13:36:42] <ronny> since when does pip ask for EVERY dependency if it should overwrite/ignore when using --download?

[17:27:47] <qwcode> pyvenv failed to install pip in 3.4.0rc3. anyone know offhand if that should be fixed in the final? or do I likely have some other problem?

[18:03:37] <dstufft> qwcode: well the final is already out, I'm not aware of any problems betweeen rc3 and the final that were fixed related to that though

[18:05:47] <qwcode> yea, I knew the final was out, this version came from a ppa, so not wanting to fiddle with altinstall if didn't have too to get latest.

[18:06:24] <qwcode> but definitely no pip. I'll look at this later, and see if I can figure out what's going on

[18:07:27] <dstufft> If it's a PPA they might have done something stupid like ripped out pip

[18:07:37] <dstufft> what ppa is it from?

[18:08:01] <qwcode> launchpad.net/~fkrull/+archive/deadsnakes

[18:08:14] <qwcode> enurepip worked to install pip globally

[18:08:56] <qwcode> looks like he just posted some new 3.4 versions in the last day though

[18:24:11] <dstufft> qwcode: ubuntu Broke ensurepip

[18:24:30] <qwcode> cool

[18:27:42] <dstufft> lists.debian.org/debian-python/2014/03/msg00045.html

[18:38:22] <qwcode> oh no. headache starting...

[18:45:28] <dstufft> *joins the mailing list*

[18:45:33] <dstufft> *expects to get told he is as hitlord*

[18:48:42] <qwcode> you could get lost for weeks in that thread

[18:49:36] <qwcode> my 3.4.0rc3 doesn't match with what they're saying. I need to grab the latest and see

[18:50:37] <qwcode> barry seems to be saying he wants pyvenv to work, so that's good

[18:51:15] <qwcode> in 3.4.0rc3, I don't experience any disabling of ensurepip or global pip installs

[18:53:59] <dstufft> does python -m ensurepip do anything?

[18:54:05] <dstufft> er python 3.4

[18:54:07] <dstufft> w/e

[18:54:29] <dstufft> I'm looking at the patches Ubuntu applies to PYthon 3.4 and they are rm -rf'ing ensurepip completely

[18:55:24] <qwcode> ah, the ppa I'm using is likely not connected to what they are doing in the official packages for next release

[18:56:12] <qwcode> but so many people use this ppa to quickly get python distros for "older" releases

[18:57:35] <qwcode> dstufft, link for revisions?

[18:58:20] <dstufft> qwcode: I was operating ont he assumption the PPA just backported the official package

[18:58:26] <qwcode> ?

[18:58:29] <dstufft> I don't know how tlink to revisions for this

[18:58:30] <qwcode> I don't know

[18:58:38] <dstufft> apt-get source python3.4

[18:58:50] <qwcode> but what ubuntu release

[18:58:58] <dstufft> Trusty

[18:59:06] <dstufft> What will be 14.04

[19:02:13] <qwcode> what is the *default* py version in trusty?

[19:02:31] <qwcode> 2.7? or 3.4?

[19:03:44] <qwcode> if this is the non-system 3.4 package, then ensurepip should pose no concern

[19:04:17] <dstufft> ``python`` will be 2.7 and will be for a long time, but it will come with ``python3`` by default and afaik only that by defaul

[19:04:56] <qwcode> well, ensurepip is a problem for them regardless I guess, if pip-3.4 is managed by them, which it is

[19:06:54] <qwcode> no, maybe there is only 'python-pip' for the default 2.7 python. that's what is in precise, not sure for trusty

[19:07:51] <qwcode> packages.ubuntu.com/trusty/python/python-pip

[19:08:23] <qwcode> packages.ubuntu.com/trusty/python/python3-pip

[19:17:32] <qwcode> dstufft, the whole situation is such an impossible dilemma currently: 1) OS people: "keep your unpackaged rogue pip out of our system", 2) python people: "but your packaged python tools (pip/setuptools/virtualenv) are old and worthless."

[19:18:34] <dstufft> qwcode: lol

[19:18:35] <dstufft> more or less

[19:20:52] <qwcode> dstufft, the only solution where both are happy is if every user self-manages all his base python installs... i.e. every user altinstalls all there pythons themself, and uses the latest tools there.

[19:21:07] <dstufft> qwcode: pyenv!

[19:24:03] <qwcode> dstufft, ok, if debian allows that to work. ensurepip has to be present for that, right? that's where pip comes from, right?

[19:24:15] <dstufft> that's pyvenv

[19:24:18] <dstufft> pyenv is something different

[19:24:18] <dstufft> lol

[19:24:21] <qwcode> oh

[19:24:24] <qwcode> ha

[19:24:29] <dstufft> github.com/yyuu/pyenv

[19:24:42] <dstufft> LETS MAKE EVERYTHING AS CONFUSING AS POSSIBLE

[19:26:54] <dstufft> qwcode: Sooo

[19:27:03] <dstufft> pip install --user as the default outside of a virtualenv

[19:27:08] <dstufft> what do you think

[19:29:23] <qwcode> good. but what always seems to come up with --user is that they hide behind easy_intall'd pkgs, due to it's pth hacks

[19:29:46] <qwcode> less of that these days, but it comes up

[19:30:27] <dstufft> Yea there's things to figure out

[19:30:49] <dstufft> but you're onboard with that at the high level?

[19:30:56] <dstufft> (devil int he details and what not)

[19:31:55] <Alex_Gaynor> the only problem with --user by default is that .local/bin isn't on anyones path

[19:32:49] <dstufft> on the other hand neither is INSTALLROOT/Scripts on Windows

[19:33:18] <dstufft> maybe we can convince the Distros to add .local/bin to $PATH by default :D

[19:33:36] <qwcode> so get-pip.py would install pip into user site as well I guess

[19:34:07] <dstufft> possibly? maybe? I dunno

[19:34:11] <qwcode> I think so

[19:35:11] <qwcode> if we can make it all work without bugs and hiccups, it's certainly ideal I think. our instructions could include modifying PATH

[19:35:38] <qwcode> it would be nice to reduce the strain with the OS pkg mgt.

[19:35:40] <dstufft> Yea possibly

[19:35:45] <dstufft> My question in general would be

[19:35:55] <dstufft> what should we do by default if the user == root

[19:36:07] <dstufft> installing into /root/.local seems less than useful

[19:36:10] <dstufft> but consistent

[19:37:58] <qwcode> make root an exception

[19:41:44] <dstufft> perhaps with a --yes-i-mean it style flag

[19:42:28] <dstufft> I think that this point we need an issue and some real discussion

[19:43:46] <qwcode> sure

[19:45:53] <qwcode> dstufft, but you're ok with debian disabling ensurepip (for the purpose of a global pip install)

[19:47:18] <qwcode> dstufft, as long as they don't also break pyvenv

[19:47:52] <dstufft> sure, I don't care if debian wants you to do apt-get install python-pip for a global install

[19:50:09] <qwcode> well, I care (because I'll get old pip), but I understand their position

[19:52:22] <dstufft> well you'll get old pip either way because ensurepip doesn't reach out to the network

[19:52:28] <dstufft> and you can pip install -U pip

[19:53:06] <qwcode> ubuntu 12.04 which is the current LTS release, has pip 1.0

[19:53:31] <qwcode> the idea with the OS-managed pip, is that you shouldn't be self-upgrading

[19:54:15] <dstufft> I agree

[19:54:20] <dstufft> but w/e

[20:10:50] <dstufft> github.com/pypa/pip/issues/1668

[20:13:15] <qwcode> you mind if I edit and add the easy_install pth concern

[20:16:41] <dstufft> not at all

[20:16:43] <dstufft> I forgot about that

[20:22:16] <qwcode> I made 2 edits. added a link to the PUG intall instructions

Log file Viewer

Help | Karma | Search:

#pypa logs for Friday the 21st of March, 2014