pmxbot IRC Log Viewer

[13:50:23] <moldy> hi

[14:39:19] <dstufft> heya!

[14:39:21] <theuni2> I'm starting to look at your pull request now.

[14:39:24] <theuni2> Give me a few minutes.

[14:39:29] <dstufft> theuni2: no problem :)

[14:40:24] <theuni2> ok so you want to get rid of the header only for the package files, right?/

[14:40:40] <theuni2> the thing that changed is that we allow people to delete files but not re-upload

[14:40:46] <dstufft> correct

[14:40:50] <theuni2> alright. i get your point.

[14:40:52] <theuni2> i agree

[14:41:04] <theuni2> I think I'd like to clean up some comments, but otherwise that's fine with me

[14:41:15] <theuni2> i'll merge that

[14:41:23] <dstufft> (techincally sometimes they can still be re-uploaded, but it requires manual intervention from a PyPI admin to allow it, so it's going to be a super rare edge case)

[14:41:24] <theuni2> if there's nothing else at the moment I can also make a release

[14:41:35] <theuni2> fair enough

[14:41:53] <theuni2> shouldn't matter from a perspective of continuous mirror operations afaict

[14:41:55] <dstufft> and if I change the URL path to include a hash like I'm thinking about doing, even then it won't matter

[14:42:03] <theuni2> right

[14:42:13] <dstufft> yea it shouldn't matter, the worst that'll happen is they'll get an error that'll get fixed the next time around instead of a retry

[14:42:19] <theuni2> yup

[14:42:53] <dstufft> and it lets us take all of the domain specific thinking out of the file endpoints, which means we can offload it easier

[14:43:16] <dstufft> I don't have anything else of important for bandersnatch right now fwiw

[14:44:13] <dstufft> theuni2: do you have a github account?

[14:45:25] <dstufft> Ah, guessed it

[14:47:24] <theuni2> i've got some more time

[14:47:31] <theuni2> so i'll do some more pull requests and review some issues

[14:47:35] <theuni2> looks like we're going python 3 today

[14:48:22] <dstufft> \o/

[14:48:37] <dstufft> oh, this was an issue -> https://bitbucket.org/pypa/bandersnatch/issue/56/setuptools-went-missing

[14:48:46] <dstufft> I fixe dit on the PyPI side, but some mirrors might be out there with missing files from it

[14:48:59] <dstufft> it's not setuptools specific, I just noticed it because of setuptools

[14:50:12] <dstufft> dunno if you want to do anything about it, but either way, should be easy to either close it as wontfix or bump the generation number

[14:55:39] <theuni2> hm

[14:55:43] <theuni2> fighting python3 and tox

[14:55:44] <theuni2> :/

[14:56:18] <theuni2> yeah

[14:56:22] <theuni2> i'll update the generation

[14:58:29] <dstufft> cool

[15:01:12] <theuni2> still fighting some weird python3 tox problem

[15:01:12] <theuni2> dang

[15:01:16] <theuni2> i thought this would be smooth

[15:01:43] <dstufft> what's the problem?

[15:03:10] <theuni2> at the moment it forgets to install pytest as a dependency

[15:03:16] <theuni2> i think i'll clear out the tox path first

[15:03:17] <theuni2> somethign weird

[15:08:14] <theuni2> ah

[15:08:20] <theuni2> i think i have a non-python3-dependency

[15:08:23] <theuni2> and that breaks the bootstrap

[15:08:30] <theuni2> weird that this didn't fail for the original committer

[15:13:03] <theuni2> sigh

[15:13:08] <theuni2> somethign with setuptools compatibility

[15:13:14] <theuni2> this is never gonna end

[15:13:21] <theuni2> i've been joking about setuptools version shit for two years

[15:13:21] <theuni2> it

[15:13:22] <theuni2> does

[15:13:22] <theuni2> not

[15:13:23] <theuni2> end

[15:13:52] <dstufft> the rapid release cycle you mean?

[15:14:05] <theuni2> the fact that the rapid release cycle breaks shit

[15:15:17] <theuni2> i don't even care any longer

[15:15:34] <theuni2> i just try to cobble together something that doesn't break in my every so specific case

[15:15:54] <theuni2> alright. yay. i got something

[15:16:34] <theuni2> wtf

[15:16:51] <theuni2> now, why is this unicode ...

[15:18:19] <theuni2> now i wish i hadn't done this merge

[15:18:27] <theuni2> obviousl

[15:18:32] <theuni2> TypeError: object supporting the buffer API required

[15:18:36] <theuni2> that keeps hitting me too

[15:19:23] <dstufft> might make sense to revert?

[15:19:51] <theuni2> yeah

[15:20:02] <theuni2> this was obviously done quite mechanically

[15:20:14] <theuni2> not watching the semantics going on

[15:20:35] <theuni2> just encoding whatever accidentally comes out of the mocked API that now so happens to be unicode won't make any sense

[15:22:21] <theuni2> uhm

[15:22:27] <theuni2> and as that was a merge i can't backout it

[15:22:57] <theuni2> hm. i just want the reverse changeset of that applied.

[15:22:57] <ionelmc> theuni2: "reverse" merge

[15:23:11] <doismellburning> theuni2: http://git-scm.com/blog/2010/03/02/undoing-merges.html ? (or is this some other VCS)

[15:23:27] <theuni2> this is mercurial

[15:23:30] <ionelmc> i suspect he's using mercurial

[15:23:39] <ionelmc> backout is mercurial jargon

[15:23:42] <theuni2> :)

[15:23:53] <theuni2> jesus. brainfuck. i should not have used the UI.

[15:24:15] <theuni2> reminder to self: merging through any hosted UI causes immediate publication of the merge changeset

[15:35:32] <theuni2> i figured it out

[15:35:56] <theuni2> —close-branch the current head and then make an extra commit on the last changeset of that branch

[15:40:21] <theuni2> dstufft: alright. i'm cutting you a release now. python 3 is still no joy.

[15:42:15] <dstufft> theuni2: awesome, thanks!

[15:42:44] <dstufft> I'm not going to pull that header right away (well I did already in Warehouse, but that's not deployed yet), but having a version out gives folks time to ugprade

[15:44:22] <theuni2> yup

[15:44:25] <theuni2> i saw your commit

[15:52:14] <theuni2> dstufft: it's out

[15:52:43] <dstufft> theuni2: thanks!

[15:53:12] <dstufft> hm

[15:53:16] <dstufft> not showing up on PyPI yet

[15:55:58] <theuni2> uhm

[15:57:09] <theuni2> something in my toolchain screwed up

[15:57:20] <theuni2> done it manually now

[15:58:07] <dstufft> awesome

[15:58:08] <dstufft> thanks!

[16:48:23] <agronholm> theuni2: python 3 problems?

[16:51:28] <theuni2> agronholm: rather problems with the changes that were provided via pull-request :)

[17:24:51] <ronny> re

[17:53:19] <tos9> Something is broken on pip HEAD with VCSes.

[17:53:55] <tos9> I am not sure what yet, because I have to fix all of our builds taht are using HEAD first. But it's running the wrong git clone command for SSH urls I think.

[17:54:41] <tos9> Specifically, it looks like somewhere between 6.0.8 and HEAD, the scheme (ssh://) isn't being used in the git clone command anymore.

[17:54:44] <tos9> CC dstufft

[17:54:56] <tos9> (I can file an issue in a minute after I do this if it isn't obvious what's broke)

[17:55:06] <dstufft> I merged a thing

[17:55:07] <dstufft> sec

[17:55:51] <tos9> https://github.com/pypa/pip/commit/06473be63119bd140b3bc837c7b33ffe325bf6ef

[17:55:58] <dstufft> https://github.com/pypa/pip/pull/2513

[17:56:05] <dstufft> yea

[17:58:18] <tos9> my requirement line is git+ssh://git@github.com/Me/MyProject.git@master#egg=MyProject, but the two test cases there are coming with no scheme.

[17:58:29] <dstufft> tos9: what is your github username

[17:58:29] <tos9> Either my version of git, or all versions of git, don't actually understand that without one.

[17:58:40] <tos9> dstufft: It's a private repo

[17:58:48] <tos9> dstufft: Oh if you just want to ping me, it's Julian

[17:58:50] <dstufft> right that's fine, I want to mention your name :)

[17:58:52] <dstufft> k

[18:04:28] <dstufft> tos9: https://github.com/pypa/pip/pull/2547 revert PR, will merge once tests pass

[18:04:41] <tos9> dstufft: Thanks.

[18:05:10] <dstufft> I'm glad folks are using HEAD in their CI, it's probably a better test suite then our test suite

[18:05:10] <dstufft> heh

[18:07:23] <tos9> Well. We're not going to be any more :) I am tired enough of fixing CI after actual releases.

[18:07:30] <tos9> So uh someone else, you can be the test dummy

[18:07:43] <dstufft> ha

[18:07:48] <dstufft> that's reasonable :)

[18:34:18] <sgu> Hi all, I got the error: Cannot locate installed-files.txt when I run `pip show --files ipython`. Any clues what might go wrong?

[18:37:56] <ronny> dstufft: btw, i figured a name for the tool, its the gumby elf

[19:05:11] <sgu> Hi all, I got the error "Cannot locate installed-files.txt" when I run `pip show --files ipython`; Any clues what might go wrong?

[20:06:38] <ronny> sgu: how did you install ipython?

[20:16:01] <sgu> ronny: pip install "ipython[all]"

[20:17:02] <ronny> hmm, then off hand no idea

[20:23:07] <sgu> ronny: to be more accurate, I used to just run `python setup.py install' , and something was not working. Then I did uninstall it by 'python setup,py install uninsall' or pip install ipython. Then install it by pip install ipython[all].

[20:23:50] <ronny> sgu: what did you do and in what folder are you

[20:23:58] <ronny> sgu: there is no setup.py uninstall

[20:23:58] <sgu> I mean `pip uninstall ipython'

[20:24:56] <sgu> I used to download the source from ipython official website and did python setup.py install as in the official instructions.

[20:26:02] <sgu> I guess I did `pip uninstall ipython'

[20:26:28] <sgu> for uninstallation.

[20:55:39] <ronny> sgu: you are in hell :) ipythons setup.py will not add uninstall metadata

[20:58:16] <ronny> sgu: why didnt you start with pip ?

[21:08:24] <carbonizer> hello everyone

[21:11:42] <carbonizer> Is there a way to force the platform information used to acquire and/or build wheels? I am trying to install packages for a 32 bit environment on a 64 bit machine, and it keeps grabbing the 64 bit wheels.

[21:16:41] <dstufft> carbonizer: um, I don't think so. But that should probably be filed as a bug

[21:16:52] <dstufft> it should use the target interpreter's values, not the machine values

[21:17:04] <carbonizer> Alternatively, is there a way to ignore pre-built wheels and build them from scratch?

[21:19:22] <carbonizer> I was successful with this setup previously, when the pre-built wheels didn't exist (I specified -m32 in the CFLAGS).

[21:20:45] <carbonizer> I should really stop making things tough on myself and just create a 32 bit VM.

[21:21:13] <dstufft> --no-use-wheel

[21:22:00] <carbonizer> oh, crap. Did I forget to RTFM? Argh. Thank you. Let me try that.

Log file Viewer

Help | Karma | Search:

#pypa logs for Monday the 16th of March, 2015