[07:59:24] <vortec> hi, i have a question. i just upgraded to pip==7.0.3 and i am trying to install a package from a private pypi server, that has a dependency that also only exists on the private pypi server. now when i run "pip install -e ." it tries to download the dependency from pypi.python.org, even though my ~/.config/pip/pip.conf has "[global] index-url = ...."
[07:59:53] <vortec> actually i downloaded the sourcecode and run "pip install -e ." in the code folder
[08:00:17] <vortec> and i want pip to download the dependency from the private pypi, not the official one. what am i doing wrong?
[08:03:18] <vortec> i just debugged further and it seems that it doesnt use pip.conf at all:
[08:17:46] <anthony25> for my project, I'm using a little program coded in C to interact with iptables where I do a setuid(0) (because I don't want it to run as root), so I have to add the +s flag to the executable
[08:18:01] <anthony25> how can I include that in my setup.py using setuptools ?
[08:19:36] <apollo13> vortec: well yes, run with -f to follow children, as you can see by 10601/0xbb8d: 141539 3 2 execve("/usr/bin/bash\0", 0x7FFF58498BB8, 0x7FFF58498BE0) = -1 Err#2it opens a new process
[08:19:52] <anthony25> apollo13: ok, so what do you propose ?
[08:20:00] <apollo13> anthony25: as I said, run it with -f
[09:26:55] <apollo13> cause xenserver has live migration now even with local storage
[09:27:24] <apollo13> and since I don't need real HA, I am fine without DRBD, also it is not really supported on XenServer which makes it kind of a pain
[09:27:48] <apollo13> reminds me that I should upgrade the xenservers at some point
[18:47:42] <lambacck> was there a recent change to the way scripts are installed on windows? I no longer see any .py files installed along with the .exe
[18:48:22] <lambacck> And that is messing with the pyramid pserve --reload functionality
[19:00:04] <dstufft> lambacck: I think we ship the .py files embedded in the exe's
[19:04:21] <lambacck> That's likely to break things that try to detect and re-run the scripts (as is the case here). I think multiprocessing also performs those kinds of tricks
[19:06:21] <lambacck> I'm looking into ways of working around it for pyramid, and may have more specific information on how it breaks.
[19:06:50] <dstufft> I'm not sure why that would break anything, that .py file shouldn't ever change?
[19:11:35] <lambacck> is in the script tacked onto the .exe
[19:11:51] <lambacck> so there is no way to re-run the same script based on sys.argv
[19:14:47] <dstufft> I think the idea is that Windows and *nix operates the same way, you get a command like ``foo`` to call, and the fact that it's foo.exe instead of foo is more or less hiddenf rom you
[19:18:24] <lambacck> keeping the exe on the end seems to make the reloader work properly
[19:22:16] <lambacck> dstufft: so the question is whether that is a pip regression or something we should fix on the pyramid side?
[19:24:36] <lambacck> or since it is a vendored distlib should I be raising the issue there?
[19:25:05] <dstufft> It's been this way in pip for awhile... I'm actually surprised nobody has noticed it before. pip has pretty much always done that when installing from wheels
[19:25:19] <dstufft> I'm not sure what the right answer is
[19:25:47] <dstufft> I don't feel comfortable making a judgement call right this moment since I don't fully understand why it did that to begin with
[19:25:49] <lambacck> well our dev machines have been around for a while and we were using easy_install because no binary dep installation on pip
[19:26:45] <lambacck> now because of wheel/binary support in pip we're all in on pip but have some lingering environments that are getting rebuilt and causing issues
[19:27:21] <lambacck> I also wonder if it is the wheel path? before the always build and install wheels was setuptools building the .exe files?
[19:27:40] <dstufft> when installing wheels pip controls the script wrapper
[19:27:46] <dstufft> when installing sdists, setuptools does
[19:28:07] <lambacck> so that is it, we had old versions that were not installed via wheel and the setuptools way worked
[19:29:20] <lambacck> And to be clear, I'm not saying either way is right or wrong but I expect that I'm not the only one who will run into it, I just might have more knowledge of where to go
[20:09:19] <lambacck> so the workaround for us at this time is --no-binary pyarmid
[20:29:09] <utek> lambacck: I see you use windows. Do you by any chance also use vagrant on windows host?
[21:45:36] <nanonyme> I have this package syscertifi which registers a module certifi.py and I'd kinda want it not to be installable if the machine already has certifi
[22:00:05] <dstufft> yea, there's nothing like that currently :(
[22:09:37] <tos9> I'm not sure I want to know the answer to these questions. But this is now the third different machine where I've seen interpreters import each others' stdlib while creating virtualenvs.
[22:10:09] <tos9> Is virtualenv doing horrible terrible things, or what possibly is explaining what's going on? Tracebacks look like bpaste.net/show/1a88bdc42406
[22:10:24] <tos9> (Where you're seeing python-future, which does terrible things, and which won't work if you somehow manage to import it in Py3)
[22:16:43] <dstufft> virtualenv is doing horrible things
[22:16:57] <dstufft> don't use -p is the best answer right now
[22:17:06] <dstufft> virtualenv is uniquely horrible
[22:17:11] <dstufft> you want to know how -p works?
[22:17:19] <tos9> dstufft: I mean I haven't had dinner yet I guess.
[22:17:46] <doismellburning> I mean, is `-p` better or worse than `--relocatable` ;)
[22:17:58] <tos9> Yeah but you can at least ignore --relocatable.
[22:18:24] <dstufft> if you have virtualenv.py installed into say python2.7/site-packages/ and you use -p python3.4, close to the top of virtualenv.py it will notice you're doing -p, and will shell out and do ``python3.4 /path/to/python2.7/site-packages/virtualenv.py``
[22:19:36] <dstufft> you can either don't use -p, and instead install virtualenv into every python and do pythonX.Y -m virtualenv instead of virtualenv -p pythonX.Y
[22:20:23] <dstufft> there is a rewrite branch which should hopefully make this better, but it's been backburnned while I work on other thinfs
[22:21:37] <dstufft> I think -p is worse than --relocatable, because -p is a core part of how virtualenv works (to the extent that something like virtualenv does indeed works)
[22:21:48] <dstufft> virtualenv.py has worse things in it than any other packaging tools
[22:22:17] <tos9> OK the first option isn't terrible I guess.
[22:22:20] <dstufft> one of my favorites is how virtualenv.py will create a copy of itself with parts of it replaced to enable people to make a custom virtualenv.py that has "hooks"
[22:22:28] <tos9> Although I guess it really mucks with my mkenv thing.
[22:22:35] <tos9> But I guess I'll work that into it.