Log file Viewer

[01:04:16] <altendky> techalchemy: sort of now

[01:28:13] <techalchemy> altendky: commented on your PR, we are gonna implement a freeze but i think we want to get yours merged... sorry for the holdup and thanks again

[01:28:28] <techalchemy> it looks right to me

[01:29:06] <altendky> techalchemy: thanks for looking some more. Did you figure anything out about the .extra dead end assignment?

[01:29:56] <techalchemy> no, these changes were made a long time ago and I have a feeling your suspicions are right

[01:33:58] <altendky> techalchemy: when did you want to merge? It would probably be good to relocate the function and add some direct tests if there's time. I could start after I do the dishes. I can grab the dependencies of some small packages to create test cases.

[01:34:58] <techalchemy> no rush, I doubt it will be today

[01:35:05] <techalchemy> need to sync up with kenneth

[05:28:53] <kaerbemevig> Hello! What could be the reason for pip to try to reach pypi.python.org when installing a dependency from Egg? The platform is Cygwin. A similar problem on Debian pointed towards an index configured for easy_install in ~/pydistutils. No such file on the Cygwin workstation, though.

[05:30:40] <kaerbemevig> --isolated is used and the indices are set with --index-url and --extra-index-url.

[05:38:17] <njs> kaerbemevig: I don't think pip can install anything from eggs?

[05:39:00] <njs> kaerbemevig: but the usual reason to run into this is if you're trying to install a package from source, then the source tree's build system (setup.py) might itself go try to download things from pypi.org without consulting pip, and pip doesn't have any way to stop it

[05:39:12] <njs> kaerbemevig: in particular this happens for packages that use the setup_requires= option

[05:39:33] <kaerbemevig> pip resorts to using easy_install's internals to install from Egg.

[05:39:59] <ngoldbaum> out of curiosity, why do you want to install from an egg?

[05:40:46] <kaerbemevig> I don't, there are things that are out of my jurisdiction.

[05:41:38] <kaerbemevig> Let me book a workstation and produce the log so you can judge it with your own eyes. I don't want to lead you astray.

[06:16:22] <kaerbemevig> Here's the log: https://pastebin.com/b0ts16Yn

[06:37:25] <Swant> Hi, I created a PyPI account yesterday, and I'm still signed in on my mobile phone, but i can't sign in on my computer today, it says "No user found with that username" which i highly doubt as I'm signed into it on my phone...

[06:37:47] <Swant> I don't get any further error messages, but is there something known that can cause this?

[06:38:47] <Swant> oh and of course, it started to work just as i had sent that...

[07:12:50] <ngoldbaum> kaerbemevig: https://github.com/pyca/pynacl/blob/master/setup.py#L219

[07:13:02] <ngoldbaum> kaerbemevig: as njs said

[08:31:46] <kaerbemevig> I was able to restrict the access to the desired indices.

[08:31:52] <kaerbemevig> Now I am getting the following error:

[08:32:26] <kaerbemevig> distutils.errors.DistutilsPlatformError: Python was built with Visual Studio version 6, and extensions need to be built with the same version of the compiler, but it isn't installed. Cleaning up...

[08:36:41] <kaerbemevig> BTW, what's the point of having setup_requires and install_requires? And why does setup_requires resort to easy_install, which uses hidden configuration?

[11:17:07] <aspiers> can anyone explain this utterly bizarre behaviour of setup_requires? https://gist.github.com/aspiers/0c54ec5b9278663823cc16e50af905c2

[11:17:37] <aspiers> am I getting DNS-redirected to an out of date PyPI mirror or something?

[11:18:13] <aspiers> but that doesn't make sense, because then my browser would not be showing the newer packages

[11:20:15] <aspiers> ah, pip install pyscaffold>=2.5.10 seems to explain it, maybe

[11:20:19] <aspiers> conflicts with existing packages

[11:21:54] <aspiers> but then the question is, why is setup_requires so hopelessly silent about the dependency conflicts?

[11:25:25] <aspiers> ahhhh ...

[11:26:28] <aspiers> but would that also fix setuptools?

[11:35:15] <aspiers> ah I guess setuptools doesn't do any dependency resolution - presumably it leaves that to pip

[11:40:04] <aspiers> this channel is pretty useful for rubber duck debugging even when it's quiet ;-)

[11:48:03] <mgedmin> (setuptools does naive dependency resolution -- but it doesn't check for conflicts against other installed packages)

[12:35:13] <aspiers> mgedmin: however it works, I really think pip install -e . or whatever should be more verbose and explanatory when it fails to fulfill setup_requires

[12:35:58] <mgedmin> the sad part is that _pip_ cannot do _anything at all_ about setup_requires because it's setuptools (running in a subprocess) that's in control

[12:36:39] <mgedmin> pip install -e spawns 'python setup.py develop' and all it can see is the subprocess's stdout * stderr

[12:37:00] <mgedmin> I really really hope that PEP-518 will replace the evil that is setup_requires Any Day Now

[12:37:30] <aspiers> ah I see, that's great info thanks