Log file Viewer
#pypa logs for Friday the 8th of May, 2015
[00:21:33] <wt> dstufft, fwiw, i am using python 2.7 with version 1.5.6 of pip (according to pip --version)
[08:52:53] <joar> if you have your package in ./src and use package_dir={'': 'src'}, the package will have different paths depending on if it's being installed or published. I need to know where my package is because I'm exec'ing a version.py file from the package in setup.py.
[11:24:14] <joar> It looked to me like I had my package in the src/ directory when running setup.py in my working tree, but when I installed the package in another environment the packages were in the top level.
[11:26:46] <ronny> joar: installation to a target will put the packages into the toplevel, but installation is different from building a source distribution
[11:56:41] <joar> ronny: the problem was that I was trying to parse src/mypkg/version.py in my setup.py, and 'src' didn't exist when I installed the package.
[12:07:06] <mgedmin> my point is: either you have setup.py and src/mypkg/version.py, or you have .../lib/pythonX.Y/site-packages/mypkg/version.py and no setup.py
[12:07:22] <mgedmin> so I'm not sure why setup.py would need to consider both possible locations for version.py
[12:08:03] <joar> mgedmin: when you install a source dist, the supplied setup.py gets executed AFAICT.
[12:19:18] <joar> This is a puzzling error: Can't uninstall 'tinbox-client'. No files were found to uninstall.
[12:22:43] <mgedmin> nicolimo86, I'm guessing not, since nobody's replying, but I'm curious: what's mobaXterm?
[12:27:10] <nicolimo86> it's a software like cygwin, used by sys admins (http://mobaxterm.mobatek.net/)
[12:30:27] <nicolimo86> Could not find a version that satisfies the requirement pip (from versions: ) No matching distribution found for pip
[12:33:41] <mgedmin> can you test python -c 'import urllib; urllib.urlopen("https://pypi.python.org/simple/pip").read()' ?
[12:34:38] <nicolimo86> IOError: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
[12:46:47] <mgedmin> more likely one of the libraries in your ssl stack cannot handle SNI, or sufficient number of SANs
[12:47:16] <mgedmin> you can work around this -- download the setuptools + pip wheels to a local directory
[12:47:59] <mgedmin> I'd link you about the get-pip command line args for offline installs, but I have to run
[12:52:31] <nicolimo86> @mgedmin I've already downloaded the get-pip.py and I tried to install it from a local directory
[12:53:02] <ronny> nicolimo86: to fully run the local download a few more files and options are needed
[12:54:27] <mitsuhiko> as far as i know there is no way to disable SSL verification and pypi is now forcing SSL on you
[13:29:42] <ronny> dstufft: btw, any oppinion on providing pip with a way to install packges into a python "foreign" to it, so pip could be in a virtualenv different from the python receiving the pacakges?
[13:43:27] <mgedmin> there's pip install --target and there's pip install --root and I've no idea what those do
[13:53:20] <dstufft> -E it was called, and it created a virutal env (or used ane xisting one) and it would essentially just re-exec itself in that virtualenv
[13:53:34] <dstufft> but it had a lot of the same problems that re-execing virtualenv.py has, so it was removed
[13:53:56] <dstufft> if someone comes up with a way that isn't fragile as hell, then it's certainly a possibility
[13:55:06] <ronny> dstufft: it already invokes python for handling installation , my idea would be to support obtaining the metadata for virtualenvs from them, and just doing installation/file removal based on metadata
[14:02:24] <DanielHolth> it seems like you should be able to just run a script in the target environment to print all the necessary destination paths, and then unpack the wheel that way.
[14:04:26] <ronny> alltho there should be some sanity checks, it would be nice if pip errored out early instead of setup.py stubmling uppon missing gcc
[14:05:49] <ronny> DanielHolth: the errors are already confusing on stock linux, its probably worse if its on windows
[14:06:04] <DanielHolth> A different way is to just make an executable zip of pip and run that with the target python. Then pip isn't importable in the target environment.
[14:06:54] <DanielHolth> would you check that fortran compiler is installed for certain scipy packages?
[14:07:55] <ronny> DanielHolth: i'd suggest handlign only the simple cases and have the complex ones be handled by build tool support later (or if someone can provide a comprehensible tested patch)
[14:08:19] <ionelmc> has anyone ever talken to the person making these wheels here: http://www.lfd.uci.edu/~gohlke/pythonlibs/ ?
[14:08:51] <ionelmc> why doesn't he make a pypi repo (there's free hosting for that at binstar, and probably others)
[14:11:08] <ronny> DanielHolth: pip should just provide a message that this is a package with extensions and no wheel was found, if it errors compiler installation may be necessary, potentially linking documentation
[14:11:57] <dstufft> maybe we should just talk to him about giving him a place to put them where he's not paying for bandwidth
[15:05:01] <DanielHolth> ronny do you expect to parse the target setup.py with AST looking for extensions keywords to the setup call, hoping that the user didn't collect the arguments into a dict and call just setup(**arguments), or perhaps look for Extension()
[15:23:28] <ronny> dstufft: i suspect anything short of obtaining the distribution and iterating it and its features for extension wont do
[15:54:47] <tdsmith> Gohlke works in my department; I've worked on projects with their lab. Never met the guy
[19:18:14] <tdsmith> does `brew doctor` say anything interesting? `brew link python` or `brew reinstall python` may work or provide informative error messages
[19:21:42] <tdsmith> `python -m pip install -U --force-reinstall pip` will probably rewrite the stubs correctly
[19:23:25] <tdsmith> probably what happened is that homebrew's python was installed as a dependency of something, which installed a pip script, which was leftover when homebrew's python was subsequently uninstalled
[19:26:43] <tdsmith> `pip install -U --force-reinstall setuptools` if your pip script is working again
[19:31:54] <tdsmith> that looks right. maybe try `rm $(which pip) $(which easy_install)` and trying to reinstall pip again
[20:05:24] <tdsmith> then there is an inconsistency between what pip claims it has done and what pip is actually doing
[20:06:19] <tdsmith> dunno! invoking pip using `python -m pip` instead of `pip` will definitely work
[20:08:26] <tdsmith> dstufft: can you imagine a situation where /usr/local/bin/pip would end up in RECORD but not actually get written to disk?
[20:12:30] <tdsmith> my last idea is adding `--no-use-wheel` when installing pip, like `python -m pip install -U --force-reinstall --no-use-wheel pip`
[20:20:24] <dstufft> not sure what your question is, pip doesn't decide where to put script files, it just asks the Python interpreter. Your Python was compiled in a way so that the scripts go into that directory
[20:20:46] <dstufft> if you don't want them to go there, I think you can control it with a config file, or you can get your Python from somewhere that doesn't put it in that dir
[20:21:18] <dstufft> I perosonally use pyenv to get my Pythons, however Homebrew is also a good choice
[20:22:56] <iCHAIT1> You mean to say that I should add the scripts path to my bash/ fish config file, right?
[20:29:58] <tdsmith> yeah i've been wrong, the python.org build is configured with a /Library scripts path. tmyk