pmxbot IRC Log Viewer

[00:25:59] <CrazyCasta> Having some trouble with namespace packages, looking for some help:

[00:25:59] <CrazyCasta> I have a couple of packages (LDB_Algebra and LDB_LAPACK), I have installed one (LDB_LAPACK) from pypi with pip, I have installed the other (LDB_Algebra) via python setup.py install.

[00:26:00] <CrazyCasta> All of this is done inside a virtualenv.

[00:26:00] <CrazyCasta> LDB_Algebra doesn't "show up", i.e. when I do "import ldb.algebra" it fails. If I don't have LDB_LAPACK installed, or if I upload to pypi and install via pip install it works great.

[00:26:40] <CrazyCasta> Is this a known issue? Is there a nice easy way that I can install my dev package in my virtualenv w/o having to upload it to pypi?

[00:27:28] <CrazyCasta> Oh, and P.S. I'm using setuptools

[00:33:02] <dstufft> github.com/pypa/pip/issues/3

[00:33:11] <dstufft> CrazyCasta: ^

[00:36:12] <CrazyCasta> so is pip install --editable roughly the same as python setup.py install then?

[00:37:16] <CrazyCasta> dstufft: ^?

[00:37:29] <dstufft> well, not exactly, but in the ways that matter for this question, yes

[00:37:38] <dstufft> I would suggest not executing setup.py install

[00:37:41] <dstufft> and using pip instead

[00:37:52] <dstufft> either pip install . or pip install path/to/tarball

[00:46:04] <CrazyCasta> dstufft: thanks, that did it! Are there any significant differences between how python setup.py install and pip install . work that I should be aware of (like how the build process works basically)?

[00:47:39] <dstufft> there's not much you need to know, it still uses setup.py to buuld it, it just forces some different defaults and works around some legacy misfeatures

[07:20:19] <mgedmin> c:\python35\python.exe -m pip list -> No module named pip.__main__; 'pip' is a package and cannot be directly executed

[07:20:42] <mgedmin> fresh install of python 3.5 on windows

[07:20:50] <mgedmin> did the python installer folks mess it up?

[07:21:07] <mgedmin> python -m getpip -> No module named getpip

[08:06:13] <mathieui> isn’t it ensurepip?

[08:06:30] <mgedmin> ah, right, mixed it up with the old getpip.py

[08:07:23] <mgedmin> yay python35 -m ensurepip installed pip and setuptools

[08:07:27] <mgedmin> and now python35 -m pip list works

[08:07:55] <mgedmin> I thought the python installer was supposed to bootstrap ensurepip as part of the installation process these days?

[08:08:26] <mgedmin> oooh, "'pip' is a package" is because there's a ./pip/ directory in $PWD

[08:08:33] <mgedmin> (containing just a pip.log of unknown age)

[08:10:27] <mgedmin> python35 -m pip install virtualenv => success

[08:10:36] <mgedmin> python35 -m virtualenv --version => 13.1.2

[08:10:59] <mgedmin> python35 -m virtualenv /tmp/py35 => GUI error dialog "Thje program can't start because VCRUNTIME140.dll is missing from your computer."

[08:11:14] <mgedmin> python installer bug?

[08:11:25] <mgedmin> why does _virtualenv_ want vcruntime140.dll?

[09:36:45] <ionelmc> mgedmin: why don't you use the rewrite?

[09:36:57] <mgedmin> complexity management

[09:37:08] <mgedmin> I want standard tools to work dammit!

[09:54:49] <ionelmc> mgedmin: weigh in to get it merged then

[09:55:25] <mgedmin> does it help in this case?

[09:55:34] <mgedmin> i.e. have you tried python 3.5 on windows?

[09:57:27] <ionelmc> https://www.irccloud.com/pastebin/bSBuJNAt/

[09:57:34] <ionelmc> mgedmin: works like a charm

[09:57:40] <mgedmin> cool!

[09:58:00] <ionelmc> maybe i should publish it on pypi

[09:58:01] <mgedmin> and can you reproduce my problem if you use stock virtualenv?

[09:58:06] <ionelmc> to make it more convenient

[09:58:31] <mgedmin> I would like to rule out local configuration snafus

[09:58:57] <ionelmc> mgedmin: i won't even try the stock virtualenv, i've worked hard on the rewrite and i would not go trough that indignity

[09:59:40] <mgedmin> even to help put nails in its coffin?

[10:00:42] <ionelmc> ok, calmed down now

[10:00:47] <ionelmc> https://www.irccloud.com/pastebin/K9YR2lcN/

[10:00:52] <ionelmc> seems to work?

[10:00:53] <ionelmc> odd

[10:01:50] <mgedmin> so it's my config that's messed up :(

[10:02:18] <ionelmc> mgedmin: i suspect you're having some issues with virtualenv's re-exec technique

[10:02:20] <mgedmin> wish I could ssh into my windows VM; rdesktop is painful

[10:02:33] <ionelmc> but does the rewrite work?

[10:02:35] <mgedmin> ionelmc, I'm running virtualenv on 3.5, why would it re-exec itself?

[10:02:50] <mgedmin> if I could ssh into my Windows VM, I'd try the rewrite in a heartbeat

[10:02:58] <ionelmc> it always re-exec with target interpreter

[10:03:06] <mgedmin> now I'd have to use an inferior shell and type in long git urls because what is clipboard

[10:03:20] <mgedmin> note: I'm not using -p

[10:03:26] <ionelmc> a

[10:05:42] <ionelmc> mgedmin: it works

[10:05:55] <ionelmc> but i got a "system install" of 3.5

[10:06:05] <mgedmin> so have I

[10:06:08] <mgedmin> what windows version?

[10:06:21] <mgedmin> maybe you have the missing VCRUNTIME140.dll from somewhere else?

[10:06:51] <ionelmc> i expect that's installed by the redistributable package

[10:06:57] <ztane> File "/usr/lib/python3.4/distutils/version.py", line 343, in _cmp

[10:06:58] <ztane> if self.version < other.version:

[10:06:58] <ztane> TypeError: unorderable types: str() < int()

[10:06:59] <ztane> :D

[10:07:01] <ionelmc> mgedmin: does your python even run at all? :))

[10:07:09] <ztane> didn't go too well...

[10:07:23] <ionelmc> ztane: what are you installing

[10:07:37] <mgedmin> yes! e.g. python -m pip install virtualenv worked fine

[10:08:15] <ionelmc> mgedmin: where is your vcruntime dll located

[10:09:36] <ionelmc> i think someone hates windows really hard

[10:10:16] <ionelmc> ok

[10:10:36] <ionelmc> can i make a package replace a different name package?

[10:10:54] <ionelmc> so if i do `pip install foo-ex` then `foo` will get uninstalled?

[10:11:15] <ionelmc> without evil distribute-like packaging tricks

[10:14:02] <mgedmin> would be nice if pip supported apt-style Provides: foo Replaces: foo

[10:14:06] <mgedmin> Conflicts: foo

[10:14:17] <mgedmin> also, I'd like a pony

[10:14:30] <ztane> ionelmc: this is a package with +ztane (a local discriminator or whatsit called)

[10:18:09] <ztane> *ah sorry this wasn't

[10:18:12] <ztane> matplotlib that is

[10:41:53] <ztane> hmm

[10:53:42] <squeaky_pl> Are there any known problems with wheel building on Python 3.5. I just deleted my Python 3.4 virtualenv and made a new one using Python 3.5 and I am suddenly hitting an assert File "/wheel_venv/lib/python3.5/site-packages/wheel/bdist_wheel.py", line 155, in get_tag

[10:53:42] <squeaky_pl> assert tag == supported_tags[0]

[10:57:00] <ionelmc> squeaky_pl: maybe you got old wheel package?

[10:57:37] <squeaky_pl> ionelmc, like where? in a pip cache or something?

[10:58:19] <ionelmc> squeaky_pl: run `wheel version`

[10:59:52] <squeaky_pl> wheel 0.24.0 also pip 7.1.2 from /wheel_venv/lib/python3.5/site-packages (python 3.5)

[11:00:42] <squeaky_pl> it only happens with wheels that contain C extensions, the pure python ones built without problems

[11:01:48] <ionelmc> squeaky_pl: setup.py script?

[11:02:34] <squeaky_pl> ionelmc, I am building packages from pypi, for example zope.interface

[11:03:02] <squeaky_pl> ionelmc, for example this https://gist.github.com/squeaky-pl/64267e65b0f4c447af40

[11:03:33] <squeaky_pl> the same happens for gevent for example

[11:04:06] <squeaky_pl> well anything that has C extensions

[11:04:20] <squeaky_pl> is Python 3.5 blacklisted somewhere?

[11:16:21] <squeaky_pl> ok

[11:16:23] <squeaky_pl> assert tag == supported_tags[0]

[11:16:23] <squeaky_pl> AssertionError

[11:16:23] <squeaky_pl> ('cp35', 'cpgnu', 'linux_x86_64') ('cp35', 'cp35m-x86_64-linux-gnu', 'linux_x86_64')

[11:16:41] <squeaky_pl> so my python is cp gnu and that is not allowed by some PEP i think

[11:17:31] <squeaky_pl> do I need to patch CPython source or how do I resolve that?

[11:19:14] <squeaky_pl> https://bitbucket.org/pypa/wheel/issues/146/wheel-building-fails-on-cpython-350b3

[11:19:20] <squeaky_pl> Ok I found my issue in bug tracker

[11:33:42] <ronny> hmm

[11:33:48] <ronny> whos the current wheel maintainer?

[11:34:20] <squeaky_pl> This problem was reported twice, also here https://bitbucket.org/pypa/wheel/pull-requests/53/use-split-instead-of-rsplit-to-create/diff

[11:36:46] <ronny> there is 3 pull requests about it by now

[11:38:00] <squeaky_pl> Well since the problem was known for 2 months at least and now Python 3.5 is final it will gain more momentum

[11:56:00] <ionelmc> ronny: looks like it's Daniel Holth?

[11:56:11] <ionelmc> he seems active on the mailing lists, someone mail him!

[11:56:12] <ionelmc> :)

[13:44:23] <ronny> dstufft: pypi and pip should add a severe warning for all pacakges that braek python and lack support contact details (like enum34)

[14:24:44] <nanonyme> I'm bumping into a version of setuptools which seems not to respect my manifest.in. Any clues?

[14:27:17] <nanonyme> IOW the files are not added to the sdist at all

[14:27:21] <nanonyme> I'm totally confused

[14:30:21] <nanonyme> It's working for me locally but not for that particular machine

[14:40:41] <ionelmc> nanonyme: can you show the project?

[16:32:21] <nanonyme> ionelmc, afraid not. I can try to come up with a minimum reproducing sample though. Basically what it's all about is there's a subdirectory under the projects which has version.json file. setup.py reads version from said file. I was trying to ship the file in the tarball which looked as if it worked correctly (worked on my own machine plus two other machines) but for some reason didn't work in CI

[16:32:33] <nanonyme> Can try to come up with one tomorrow, that is

[16:32:42] <nanonyme> I don't atm have access to the machine where it broke

[16:33:01] <nanonyme> The manifest.in basically just has "include subdirectory/version.json" inside it

[16:33:39] <ionelmc> nanonyme: random guess: maybe you run setup.py from the wrong working directory?

[16:33:50] <ionelmc> almost random :)

[16:34:32] <nanonyme> That's a good guess but I don't think it's that. I know the exact command for running the setup.py and it doesn't have a path to it, just setup.py

[16:35:23] <nanonyme> There's some egg_info magick involved in the project for adding dev version suffix but it doesn't affect anything on my production machine

[16:37:47] <nanonyme> Since there's nothing in logs related to the included file, I can't be sure whether it's just not seeing the file and is silently ignoring it or isn't going through the manifest.in at all

[16:38:16] <ionelmc> nanonyme: dirty build directory then?

[16:38:45] <nanonyme> It shouldn't be.... I checked the CI workspace afterwards and the json is in the right place

[16:40:11] <nanonyme> Meh, I'll review it again tomorrow

[16:43:28] <dstufft> nanonyme: do you already have a MANIFEST file

[16:43:33] <dstufft> (note the lack of .in)

[16:44:37] <nanonyme> Ooh, that's an interesting point

[16:44:58] <nanonyme> I'm not sure, I'll definitely check that tomorrow

[16:45:22] <nanonyme> dstufft, that is, I could probably confirm that by checking after build that there is a MANIFEST file which contains my line, right?

[16:47:47] <nanonyme> Or rather, if there is a MANIFEST file which doesn't contain my include, something wicked this way comes

[16:50:17] <dstufft> nanonyme: in particular, if the buld process finds a MANIFEST file, it will ignore MANIFEST.in

[16:52:28] <nanonyme> Aha

[16:53:37] <nanonyme> Yeah, I kinda guessed that from what you said

[18:53:09] <tdsmith> nanonyme: also is there a chance you've named it literally "manifest.in" and you're working on a case-insensitive filesystem (OS X default) on your work system but not on CI, and setuptools is particular?

[20:01:19] <nanonyme> tdsmith, well, that might well be the case but I would have needed PR to verify it

[20:03:15] <nanonyme> tdsmith, I did literally name it manifest.in and it worked on Windows which has case-insensitive filesystem. *However*, I also tested it on multiple Linux systems and didn't get the same behaviour there either

[20:03:32] <nanonyme> It might be the build server has a particularly old version of setuptools which is behaving odd

Log file Viewer

Help | Karma | Search:

#pypa logs for Tuesday the 15th of September, 2015