pmxbot IRC Log Viewer

[00:45:29] <dstufft> tomprince: heh

[00:45:30] <dstufft> tomprince: figured it out

[00:46:50] <dstufft> tomprince: I have to give my daughter some meds, but if you do ``pip install pip+https://github.com/dstufft/pip.git@fix-local-versions`` you should have it fixed

[00:46:56] <dstufft> I need to figure out how best to test this

[00:47:01] <dstufft> but that should have the fix in it

[00:54:24] <msabramo> @dstufft: https://github.com/pypa/readme/pull/13

[01:10:16] <dstufft> msabramo: yea I know, I'm not super focused on non pip/setuptools right this moment

[01:10:41] <msabramo> dstufft: ok, I'll give you some space :)

[01:33:54] <msabramo> what's the thought on when pip 6 will land?

[01:34:37] <dstufft> msabramo: "soon", there's another setuptools release that I want to happen first so I can pull it into pip and virtualenv, then a few days to make sure things calmed down on that front

[01:35:17] <msabramo> should be a merry pipxmas

[01:36:09] <msabramo> holy cow py32 is so much better

[01:36:43] <msabramo> < 5 minutes

[01:36:45] <dstufft> jaraco: oh hey, didn't see you come back \o/

[01:36:50] <dstufft> jaraco: you're awesome :)

[01:37:12] <dstufft> msabramo: yea, now i'm sad that A) I didn't think of doing something serially first and B) I didnt' eralize i fixed it accidently D:

[01:37:18] <msabramo> now we just need a way to make Travis cache the warmed up JIT-state of PyPy and all will be great

[01:37:39] <msabramo> dstufft: it's funny that you fixed it accidentally

[01:37:47] <dstufft> I just started running the unit tests before the integration tests to fail fast instead of doing all the slow integration crap if the unit tests wouldn't pass

[01:37:59] <dstufft> and since the unit tests are fast there wasn't any reason to parallel em

[01:38:15] <msabramo> I'd love to work with people that are so good that they accidentally get stuff done :)

[01:38:32] <dstufft> msabramo: monkeys typewriters etc

[01:38:39] <msabramo> haha

[01:38:58] <msabramo> my accidents are not so fortuitous

[01:48:16] <msabramo> https://github.com/pypa/pip/pull/2221

[01:50:55] <msabramo> ^ displays version of packages for both install and uninstall — e.g.: pytest-2.6.4; no == so we don't box ourselves in on that

[01:55:59] <pmxbot> jaraco pushed 6 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[01:55:59] <pmxbot> Silence PEP440Warning by default unless invoking easy_install

[01:55:59] <pmxbot> Merge pull request #23 from dstufft/silence-pep440-warnings

[01:55:59] <pmxbot> Update changelog; fixes #306.

[01:55:59] <pmxbot> Bumped to 8.2.1 in preparation for next release.

[01:55:59] <pmxbot> Added tag 8.2.1 for changeset efbe39dae0ab

[01:55:59] <pmxbot> Bumped to 8.2.2 in preparation for next release.

[06:18:04] <msabramo> might've found a bug in setuptools 8.2.1

[06:42:17] <dstufft> msabramo: another one QQ

[06:42:20] <dstufft> what's this one

[06:42:49] <msabramo> dstufft: https://bitbucket.org/pypa/setuptools/issue/307/pep440-code-in-setuptools-821-is-parsing

[06:52:43] <dstufft> msabramo: lol sob

[06:53:05] <msabramo> unless hyphen in package name is illegal now

[06:53:27] <msabramo> I wish I chose underscore now

[06:54:25] <dstufft> no it's not illegal

[06:56:10] <dstufft> the problem is that given a filename like setpuoolt-markdown-1.0.tar.gz

[06:56:17] <dstufft> setuptools-markdown-1.0.tar.gz

[06:56:21] <msabramo> hehe

[06:56:36] <dstufft> there's no way to parse that so you know what the version is and the name (in a pre-PEP 440 world)

[06:56:41] <msabramo> kinda hard to pick out the version

[06:56:54] <dstufft> so setuptools actually generates a list

[06:56:55] <dstufft> :/

[06:57:05] <dstufft> of all the possible combos

[06:57:21] <msabramo> whoa

[06:57:40] <msabramo> and then it sees that "setuptools" exists so it figures that was a good way to split it?

[06:58:12] <dstufft> I'm not sure what it does after that exactly

[06:58:32] <msabramo> cuz unfortunately there are a lot of packages setuptools-*

[06:58:33] <msabramo> https://pypi.python.org/pypi?%3Aaction=search&term=setuptools-&submit=search

[06:58:43] <dstufft> but I know it just more or less splits on - and parses the versions "", "1.0", "markdown-1.0"

[06:58:52] <dstufft> oh this'll happen for anything with a dash in the name

[06:58:59] <dstufft> the setuptools part isn't signifcant

[06:59:04] <msabramo> ah ok

[06:59:20] <msabramo> <- prying the hyphen key off his keyboard

[06:59:44] <dstufft> it gets worse too

[06:59:49] <dstufft> because 1-1 is a valid version

[06:59:55] <dstufft> and foo-1 is a valid package name

[06:59:58] <dstufft> foo-1-1

[07:00:20] <dstufft> is that foo-1 version 1, or foo version 1-1, or foo-1-1 without a version

[07:04:38] <msabramo> sigh

[07:04:45] <msabramo> I'm probably going to rename that package anyway

[07:04:58] <msabramo> it was too limiting to put markdown in the name

[07:05:14] <msabramo> it uses pypandoc so it can read any format and convert to reST

[07:05:28] <msabramo> not sure what to call it though

[07:05:38] <msabramo> setuptools underscore <something>

[07:06:00] <msabramo> maybe I'll sleep on it

[07:06:02] <msabramo> good night all

[14:18:32] <msabramo> Is there some function in pkg_resources or something for parsing metadata files like PKG-INFO?

[14:18:54] <msabramo> although maybe just splitting on the first colon is good enough

[14:30:11] <msabramo> hmmmm not really because of big multi-line fields like "Description:"

[14:35:52] <DanielHolth> https://bitbucket.org/pypa/wheel/src/tip/wheel/pkginfo.py?at=default

[14:38:00] <msabramo> DanielHolth: Thanks!

[14:38:08] <msabramo> did that come from http://pythonhosted.org//pkginfo/distributions.html ?

[14:43:02] <msabramo> ah looks like pip has one too

[14:52:13] <DanielHolth> wheel just has its own which is an application of the standard email module. It's easier to do correctly in Python 3.4's email module

[14:54:02] <msabramo> maybe in the next version it should be JSON or YAML?

[14:55:42] <DanielHolth> It already is JSON in the next version

[14:57:06] <DanielHolth> bdist_wheel .dist-info directories contain a metadata.json that resembles the draft spec

[15:01:14] <msabramo> oh sweet

[15:01:23] <msabramo> guess I need to read more PEPs

[15:01:41] <msabramo> what's the latest one?

[15:01:55] <msabramo> Metadata 2.0?

[15:02:16] <msabramo> PEP 426?

[16:15:07] <dstufft> pf_moore: Windows really doens't let you do ENV=whatever cmd? D:

[16:17:00] <Wooble> dstufft: tcsh doesn't even let you do that.

[16:17:26] <dstufft> maybe people should just stop using bad shells

[16:33:23] <pf_moore> dstufft: nope - why would anyone want to, depending on env variables is a horrible Unix practice ;-)

[16:34:04] <pf_moore> It's probably trivial to emulate in a powershell function, but nobody bothers

[16:34:42] <dstufft> pf_moore: :D

[16:35:16] <dstufft> probably if windows doesn't allow that, if/when we merge it, we should probably have a "hey you assholes didn't consider my situation so turn back on ascii" flag

[16:36:09] <pf_moore> I really think off by default (at least on Windows) is better. Unicode exceptions cause so much hate :-(

[16:36:30] <pf_moore> See, just talking about Unicode on Windows made msabramo quit ;-)

[16:37:24] <dstufft> lol

[16:38:25] <dstufft> pf_moore: so I'm not like, deadset on getting it in but I think that not having it at all is better than off by default, the only reason to do it is the output is slightly nicer, and I don't really see much value in a flag to make output slightly nicer (I do see value in a flag to unbreak the slightly nicer hting in the case it does break)

[16:39:08] <pf_moore> Fair point.

[16:39:26] <dstufft> in either case, I'm totally fine with punting on it till after pip 6

[16:40:41] <pf_moore> But on but broken is horrible, and these things tend to only come up when someone's running an Arabic-configured PC with right-to-left text in a directory named with Korean characters (or something like that ;-))

[16:41:15] <pf_moore> Let's leave it till after pip 6, then put it in and I'll try to break it

[16:41:31] <pf_moore> Not that I have an Arabic PC setup, of course...

[16:42:17] <dstufft> pf_moore: possibly an enhancement is to also restrict it to utf8 encodings, I'm not all that great at encodings and I don't know in which cases the characters being used will fail or not

[16:42:37] <dstufft> I *think* that the encode step will cause it to only happen if the encoding that is in use supports those characters

[16:42:47] <dstufft> which might only be utf8 I dunno

[16:45:01] <dstufft> (I'm really excited for pip 6, I have a few issues to fix and I want to wait a few days to make sure no more setuptools issues but it's so close :D)

[16:52:37] <pf_moore> I know, it's like another Christmas present :-)

[17:06:59] <msabramo> > depending on env variables is a horrible Unix practice

[17:06:59] <msabramo> ?

[17:07:24] <msabramo> better tell the 12factor guys that - http://12factor.net/config

[17:56:11] <msabramo> Are there any wheels out there that have all the latest, greatest PEP 426 metadata in them — e.g.: "source_url", "source_label", etc...?

[17:57:05] <dstufft> that metadata isn't final yet so i wouldn't want to try and support it

[17:59:36] <msabramo> ah ok

[18:01:30] <msabramo> I thought I remembered an issues_url metadata; is there not one?

[18:02:21] <msabramo> oh project_urls I guess in PEP 0459

[18:02:38] <msabramo> also a draft, probably shouldn't try to support it?

[18:04:43] <dstufft> yea don't support it

[18:04:58] <dstufft> there is a bug_tracker metadata... but it's only on pypi it's not in the packaging formats

[18:18:43] <msabramo> k

[18:18:44] <msabramo> https://github.com/pypa/pip/pull/2232

[18:18:49] <msabramo> supports wheels now

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Friday the 19th of December, 2014