pmxbot IRC Log Viewer

[00:22:48] <nicksloan> dstufft: working on that thing this weekend. The question is how to invoke pip: subprocess.call, and then I have to proxy the I/O, OR try to somehow use the distutils configuration of the selected environment, and then call pip.main... that seems like it could be complicated. Any thoughts?

[00:23:20] <nicksloan> the first option seems easily and brittle, the second option seems complex, but more enduring.

[00:23:25] <nicksloan> *easy

[00:23:59] <dstufft> pip doesn't really have an API :/ subprocess is probably closer to what we try to keep stable, though pip.main() is basically the same as subprocess just using the current python interpreter instead of spawning a new one

[00:24:22] <nicksloan> yeah.

[00:24:51] <nicksloan> and I suspect there might be issues, for example, installing with a 3.x interpreter into a 2.x environment

[00:25:00] <dstufft> yea

[00:25:07] <dstufft> probably best to subshell

[00:25:14] <dstufft> you can do python -m pip though

[00:25:18] <dstufft> so you don't have to locate the correct pip binary

[00:25:22] <dstufft> just the correct python binary

[00:25:36] <nicksloan> oh, that would be very useful

[00:25:42] <nicksloan> didn't think of that

[05:20:50] <The-Compiler> I'm trying to install https://pypi.python.org/pypi/pyPEG2/2.15.0 as a dependency inside setup.py (with setuptools), and for some reason it tries to pick the macosx archive and can't install it - doing "pip install pypeg2" works though. Why is that? See https://github.com/The-Compiler/qutebrowser/issues/250 for outputs.

[07:43:09] <mgedmin> 503 backend read error from pypi again

[07:44:14] <mgedmin> on this page: https://pypi.python.org/pypi/cassette/0.3.5

[07:44:40] <The-Compiler> mgedmin: works fine here

[07:44:42] <mgedmin> which is what google "cassette python" gives me; any ideas how we could gently persuade google to link to versionless pypi-pages?

[07:45:53] <mgedmin> anyway, still 503

[16:37:01] <[Tritium]> I am looking for the actual code that implemented issue 258 in setuptools (ms visual c compiler for python), but cannot find the commit. anyone know the commit that changed that?

[16:37:33] <[Tritium]> oh ofcourse I ask that THEN find it

[16:40:50] <nedbat> after releasing an official version, i want to set my version number to something unofficial and dev-like. What is the best practice for that version number?

[16:43:05] <doismellburning> nedbat: we use `_version = "3.0.dev%s" % int(time.time())`

[16:43:20] <doismellburning> nedbat: which is pep-whatever-it-is compatible

[16:43:31] <nedbat> doismellburning: and you add the time so that your dev versions increment?

[16:43:37] <doismellburning> nedbat: exactly

[16:43:47] <doismellburning> it's a hacky reimplementation of some of Maven snapshot

[16:50:33] <nedbat> doismellburning: thanks!

[16:50:38] <[Tritium]> ok, time to go bug #devpi for why this isnt working!

[17:03:47] <nedbat> if we (edX) have dozens of packages to upload and maintain, is there some kind of group facility on PyPI we can use so we can make a person a maintainer of all of them at once?

[17:45:36] <tomprince> nedbat: https://github.com/warner/python-versioneer

[17:45:59] <tomprince> nedbat: re: group facility. I think that is planned for warehouse, but doesn't exist yet.

[17:46:31] <doismellburning> is warehouse the new crate?

[17:46:41] <apollo13> yes

[17:49:53] <dstufft> nedbat: what tomprince said, not currently though I plan on it eventually

[17:49:54] <tomprince> (Unfortunately, versioneer doesn't support pep440 yet)

[18:14:05] <carljm> doismellburning: that time.time() trick is neat, I think I'll start using it. I've been using manually-incremented integers there, which is a pain.

[18:15:16] <carljm> (aside: the problem I tend to have is that in small projects it's not worth using a branch-for-bugfix-releases flow, so often after releasing e.g. 2.3 I don't know what will be next. It could be 2.4, or 2.3.1, or 3.0 - it all depends what type of fixes crop up or features are contributed.)

[18:16:21] <carljm> (so given that I don't know what will be next, I prefer going to 2.3.postX rather than 3.0.devX -- but I'm not sure that's PEP-whatever compliant. Need to look into it.)

[18:16:43] <doismellburning> nod

[18:16:59] <carljm> (PEP 440)

[18:17:29] <apollo13> carljm: I think both are fine

[18:17:45] <apollo13> pep fine that is^^

[18:18:00] <carljm> yeah, looks like PEP 440 allows .postX

[18:18:31] <carljm> I'm not sure it matches what others might expect from such a version number (I know some projects use post-releases for e.g. fixing up packaging issues, not for development on the next version), but whatever

[18:18:42] <apollo13> let me patent .post + time.time() then

[18:19:11] <apollo13> I'll be soooo rich

[18:19:14] <carljm> heh

[18:23:13] <buck1> how would i pip install an extension with debug symbols enabled?

[18:23:37] <buck1> pip install --more-gdb-flags="-g"

[18:23:46] <buck1> gcc*

[18:26:24] <nedbat> a co-worker needs to recover his pypi account, isn't sure what email address it's sending resets to. calen.pennington is the user name (which works, I just made it an owner of a package)

[18:31:36] <dstufft> carljm: PEP 440 suggests that .post is only used for non code changes, but it doesn't require it

[18:31:41] <dstufft> though it won't be marked as a pre-release

[18:33:23] <tomprince> carljm: You could just increment the least significant number and add .dev. You don't need to release that version.

[18:33:43] <dstufft> carljm: generally I just know what the "minimum" next version is going to be (e.g. I'm only ever going to use 3 digits or whatever) so I just increment the last number

[18:33:48] <dstufft> e;fb

[18:36:24] <dstufft> nedbat: ask him if @wgen.net rings a bell

[18:39:43] <nedbat> dstufft: "oh, ....!"

[18:39:48] <nedbat> dstufft: thanks

[18:39:59] <nedbat> dstufft: can I ask you to change it?

[18:41:24] <dstufft> nedbat: for that he'll need to file a support ticket, not that I distrust you, but recovering usernames is a stickier thing :)

[18:41:38] <dstufft> http://sourceforge.net/p/pypi/support-requests/

[18:42:21] <nedbat> dstufft: we are pleased that you are careful! :)

[18:42:31] <nedbat> thanks

[18:48:22] <carljm> dstufft: aha, yeah, i thought there was some stronger indication in there that this was a mis-use of .post. And having pip not treat it as a pre-release is problematic.

[18:48:40] <carljm> dstufft, tomprince: yep, I think just doing .dev for the next lowest possible release number is probably the best plan.

[19:04:38] <The-Compiler> I'm trying to install https://pypi.python.org/pypi/pyPEG2/2.15.0 as a dependency inside setup.py (with setuptools), and for some reason it tries to pick the macosx archive and can't install it - doing "pip install pypeg2" works though. Why is that? See https://github.com/The-Compiler/qutebrowser/issues/250 for outputs.

[19:12:00] <dstufft> The-Compiler: the answer is kind of sad

[19:12:12] <dstufft> basically prior to PEP 440 a version could be *anything*

[19:12:33] <dstufft> A sdist takes the form of projectname-version.tar.gz

[19:12:44] <dstufft> a bdist_dumb takes the form of projectname-version-arch.tar.gz

[19:13:01] <dstufft> if you look, at the output -> Best match: pyPEG2 2.15.0.macosx-10.10-x86-64

[19:13:23] <dstufft> it's seeing the bdist_dumb as pyPEG2 version 2.15.0.macosx-10.10-x86-64

[19:14:13] <apollo13> but what is the diff between install_requires and manual install?

[19:14:37] <dstufft> it's not manual install vs install_requires

[19:14:40] <dstufft> it's pip vs setuptools

[19:14:51] <dstufft> pip doesn't install pre-releases by default

[19:15:08] <dstufft> and 2.15.0.maxosx-10.10-x86-64 looks like what pip considers a pre-release

[19:15:29] <The-Compiler> dstufft: so what action can/should I take (pin the version in setup.py until this is fixed?) and what action should the pyPEG2 maintainer take?

[19:16:21] <dstufft> delete the bdist_dumb

[19:16:28] <dstufft> bdist_dumb are terrible anyways

[19:16:49] <dstufft> they are for most purposes, completely useless

[19:16:58] <dstufft> they hardcode the entire path to every file starting with the root of the FS

[19:19:18] <The-Compiler> okay, will tell them that :)

[19:59:42] <pf_moore> If I use --extra-index-url (or --find-links) with pip, and there's a wheel on PyPI and one in my index, for the same version etc, which one takes precedence?

[20:01:13] <dstufft> pf_moore: it'll be the order defined IIRC

[20:01:41] <pf_moore> dstufft: is PyPI first or last?

[20:01:46] <dstufft> so the default index is first (unless using --no-index-url), then uh, any --extra-index-url's, in the order defined, then any --find-links, in the order defined

[20:01:49] <dstufft> I *think*

[20:02:30] <pf_moore> OK, ta. I can look at the source if I need to be sure

[20:03:31] <pf_moore> Reason I ask - if I have a numpy wheel I built in my index, because there's none on PyPI, and then the numpy folks release a hugely optimised, go-faster stripes wheel on PyPI, I still get my own one until I notice and remove it? *sadface*

[20:05:34] <dstufft> pf_moore: fwiw I don't think we currently *promise* that property

[20:05:47] <dstufft> I think it's mostly an accident of implemention

[20:05:54] <carljm> pf_moore, dstufft: IIRC setuptools did something weird there (I think the shortest link won?)

[20:06:07] <carljm> And I think for a long time at least pip copied that behavior in order to be compatible.

[20:06:13] <dstufft> I don't know what setuptools does

[20:06:13] <carljm> If that's been changed recently, I wouldn't know.

[20:06:20] <dstufft> this is our PackageFinder

[20:06:27] <dstufft> for wheels anyways

[20:06:32] <pf_moore> carljm: That sentence can probably just be generic: "setuptools did something weird" :-)

[20:07:04] <carljm> pf_moore: may not even need the past tense (sorry jaraco) :-)

[20:07:33] <pf_moore> But yeah, the main thing for me is if it's a possibility, I want to make my local cache delete things that hide PyPI versions. Sigh.

[20:07:54] <dstufft> sounds like a good idea in general tbh

[20:09:19] <pf_moore> dstufft: yes it does, but it means I write *yet another* bit of pypi-querying code. It's going to be more code than building the flipping wheels in the first place. Hey ho...

[20:09:40] <dstufft> pf_moore: well building the wheel in the first place is largely just ``pip wheel`` :D

[20:09:52] <dstufft> but yea

[20:09:52] <pf_moore> blast - you noticed :-)

[20:09:52] <dstufft> :/

[20:10:03] <dstufft> pf_moore: the json endpoints on PyPI might be more useful for this

[20:10:07] <dstufft> if you're not using them already

[20:10:20] <pf_moore> OTOH, if I'm writing that, then writing code to spot wininst installers and run "wheel convert" on them becomes easier

[20:10:59] <pf_moore> dstufft: Yep, I'll probably use that

[20:11:46] <pf_moore> or maybe xmlrpc - depends if I want to bite the bullet and add dependencies (requests)

[20:15:47] <dstufft> pf_moore: eh, you can use urllib too

[20:16:34] <dstufft> I mean xmlrpc isn't going to authenticate the TLS

[20:16:43] <dstufft> if that's why you were thinking of requests

[20:17:27] <Alex_Gaynor> dstufft: 2.7.9!

[20:17:50] <dstufft> I'm guessing pf_moore is using 3.x :D

[20:18:20] <dstufft> but on Windows, which I don't think the cadefault=True argument works there

[20:27:26] <pf_moore> yep, I'm 3.x. But for JSON, requests.get('...').json() is just so cool.

[20:27:44] <pf_moore> I wasn't thinking much about TLS, TBH.

[20:27:56] <pf_moore> But I should - requests it is.

[20:28:11] <dstufft> I might have been projecting about TLS there :)

[20:28:34] <pf_moore> more like you've brainwashed me and you're checking it stuck ;-)

[20:29:27] <dstufft> might be a side effect of the fact I learned to program by hacking video games :D

Log file Viewer

Help | Karma | Search:

#pypa logs for Monday the 10th of November, 2014