pmxbot IRC Log Viewer

[01:59:54] <koobs> Can anyone help with ECLUE on these test suite failures? https://dpaste.de/0rJ9/raw

[01:59:56] <koobs> cc dstufft

[02:01:07] <dstufft> koobs: you're running into the broken behavior that's the impetus for us to remove the de-vendoring support

[02:01:08] <dstufft> :/

[02:01:17] <koobs> im not devondring?

[02:01:20] <koobs> devendoring

[02:01:47] <dstufft> yea, but we have some crazy import hook that's always active to support the de-vendoring

[02:01:56] <koobs> how do i fix it ?

[02:02:20] <koobs> so !vendoring tests are broken because of half-devendoring supporting?

[02:02:23] <dstufft> I'm not sure why it's failing there though... I've never seen it fail without someone trying to de-vendor

[02:02:24] <koobs> s/supporting/support

[02:02:28] <koobs> right

[02:02:36] <koobs> well the only test_requires im missing are pytest-xdist

[02:02:45] <koobs> i ported capturelog and updated scripttest to 1.3

[02:02:52] <dstufft> if you can apply a patch, try remove the contents of pip/_vendor/__init__.py

[02:02:54] <koobs> would missing xdist cause an issue ?

[02:03:18] <koobs> i *was* doing this:

[02:03:19] <koobs> - "pip%s=pip:main" % sys.version[:1],

[02:03:23] <koobs> - "pip%s=pip:main" % sys.version[:3],

[02:03:32] <koobs> but the tests flake out coz they have hardcoded script names

[02:03:48] <koobs> but other than that no patches

[02:03:51] <dstufft> we need to get around to baking in proper support for that too

[02:04:11] <dstufft> koobs: can you try applying one that just removes the contents of pip/_vendor/__init__.py

[02:04:14] <dstufft> so it's an empty file

[02:04:19] <dstufft> that'll get rid of the crazy import hooks

[02:04:33] <koobs> can i rm the file, or does it need to be empty ?

[02:04:40] <koobs> i imagine it still needs to be a module

[02:04:41] <dstufft> it needs to be empty

[02:04:42] <dstufft> yea

[02:04:46] <koobs> gah, hang two

[02:04:59] <dstufft> that will either work, or it'll give us the real error message that's being masked

[02:05:17] <dstufft> alternative, you can just patch out the last couple lines if that's easier -> https://github.com/pypa/pip/blob/develop/pip/_vendor/__init__.py#L104-L108

[02:05:30] <koobs> testing

[02:05:40] <koobs> w/ empty file

[02:05:48] <koobs> dstufft: can you sort out tests_require ?

[02:05:57] <koobs> or should i PR ?

[02:06:04] <koobs> not sure if you want to read from requirements

[02:06:19] <dstufft> are we using tests_require now, or are you asking us to use it

[02:06:56] <koobs> tests_require is incomplete

[02:07:05] <koobs> virtualenv >= 13.x is required (no_wheel)

[02:07:15] <koobs> but setup.py says >=1.10

[02:07:35] <koobs> and other requirements are missing

[02:07:59] <koobs> pretend, capturelog timeout

[02:08:11] <koobs> the rest probably are optional

[02:08:19] <koobs> except *many* tests fails when bzr is not installed

[02:08:23] <koobs> let me make a list up

[02:08:42] <dstufft> yea, we have test dependencies that can't be expressed inside of a tests_require

[02:08:45] <dstufft> like git

[02:09:06] <koobs> premise is the tests should run/fail if bzr (or things it needs arent there)

[02:09:08] <koobs> skipIF

[02:09:18] <dstufft> I think there's an open ticket for that...

[02:09:24] <dstufft> maybe even a PR

[02:09:41] <koobs> might have been mine

[02:09:45] <koobs> ill make a list up and search open tickets

[02:09:50] <koobs> then make a checklist in that one issue

[02:09:57] <koobs> easier to track/resolve

[02:10:17] <koobs> Still 3 failures after emptying __init__.py

[02:10:21] <koobs> When it finished ill paste

[02:10:40] <koobs> interesting too: collected 555 items / 2 errors - before running tests

[02:12:28] <dstufft> the error from the vendor meta importer was probably masking something

[02:14:42] <koobs> dstufft: https://dpaste.de/NxLs/raw

[02:15:22] <dstufft> oh

[02:15:27] <dstufft> it's collecting inside the build dir

[02:15:48] <dstufft> how are you invoking the test suite

[02:15:52] <dstufft> IIRC you don't use tox

[02:15:55] <koobs> :|

[02:16:00] <koobs> test command (invokes py.test

[02:16:12] <dstufft> try doing something like

[02:16:15] <dstufft> py.test tests

[02:16:19] <koobs> class PyTest(TestCommand):

[02:16:30] <dstufft> so that it scopes it only collecting from the tests directory

[02:16:33] <koobs> yeh no 2 errors

[02:16:44] <koobs> letting it run, seeing if theres a test delta

[02:16:47] <dstufft> you can probably remove that patch to _vendor too

[02:16:55] <koobs> other 3 errors still reproducible

[02:17:09] <dstufft> yea

[02:17:18] <dstufft> that's all with the completion script

[02:17:27] <dstufft> sadly, I have like no idea how shell completion works

[02:17:31] <dstufft> I just ignore that bit of code :/

[02:17:35] <koobs> thats fine, probably shell assumptions

[02:17:40] <koobs> ive seen it a gazillion times

[02:17:55] <koobs> at least ive ported (and using) pytest-capturelog now so its not that

[02:18:04] <koobs> dstufft: how do we fix class PyTest?

[02:19:45] <koobs> dstufft: i had a question yesterday, currently tests invoke pip or pip2.7, is there anyway to make those invocations the same as how console_scripts are rewritten for the python interpreter its installed with ?

[02:20:05] <koobs> that way it only tests the script name that is *actually* installed

[02:20:06] <dstufft> koobs: might try adding "tests" to the list here https://github.com/pypa/pip/blob/develop/setup.py#L24

[02:20:31] <koobs> dstufft: that feels hacky?

[02:20:40] <koobs> or is there a reason why the default scope is off ?

[02:21:10] <dstufft> actually

[02:21:18] <dstufft> why isnt it respecting norecursedirs

[02:21:34] <dstufft> oh

[02:21:39] <dstufft> because I'm looking at warehouse's

[02:22:06] <koobs> :]

[02:22:17] <koobs> yeh doesnt like tests as an arg

[02:22:21] <dstufft> adding a line like ``norecursedirs = .tox build dist node_modules *.egg-info`` to https://github.com/pypa/pip/blob/develop/setup.cfg#L2 might make it ignore the build dir

[02:22:23] <koobs> NameError: global name 'tests' is not defined

[02:22:25] <koobs> *** Error code 1

[02:22:42] <koobs> dstufft: test command uses pytest not tox dont forget

[02:22:52] <dstufft> yea, that's not a tox thing

[02:22:57] <koobs> right

[02:23:00] <dstufft> that's telling py.test what directories not to recurse into

[02:23:19] <koobs> mm

[02:23:38] <dstufft> sorry, I've got a bunch of crap open for Warehouse and it's a little torn apart right now

[02:24:33] <koobs> better

[02:24:39] <koobs> all good

[02:24:49] <koobs> no more errors with that in setup.cfg

[02:24:59] <koobs> <3

[02:25:32] <dstufft> as far as the console_scripts, what are you trying to do, remove, add, or change

[02:25:59] <koobs> dstufft: some of the tests invoke `pip` or `pip2.7`

[02:26:05] <koobs> right?

[02:26:27] <koobs> since i see them fail if i comment out the versioned console_scripts entries (leaving only` pip`)

[02:26:37] <koobs> since we version them ourselves (with symlinks)

[02:26:38] <dstufft> should mostly be ``pip`` unless we had an explicit reason to check the pipX.Y

[02:26:57] <koobs> there are tests that are hardcoded for pip and pip2.7, the name is orthogonal

[02:27:07] <koobs> the tests should use the name *as* installed by console_scripts

[02:27:48] <koobs> im runnign the tests now (having comment out the versioned console_scripts entries)

[02:28:28] <koobs> dstufft: https://dpaste.de/P0sp/raw

[02:28:32] <koobs> theres one example

[02:28:45] <koobs> resulting in:

[02:28:46] <koobs> > raise child_exception

[02:28:48] <koobs> E OSError: [Errno 2] No such file or directory

[02:28:52] <koobs> of course, since it wasnt installed

[02:30:51] <dstufft> so that's a test that explicitly is testing to make sure that pipX.Y works

[02:31:07] <dstufft> I'm not sure it's possible to modify that in any way

[02:31:46] <koobs> sounds like a nice lib function to check if script/binary is installed before use and if not skip

[02:32:07] <koobs> which wouyld benefit the other tests that fail for the same reason

[06:38:20] <tdsmith> is the most correct way to include .h files in an sdist listing them in MANIFEST(.in)?

[06:39:23] <tdsmith> assuming that they need to be present for an extension to be compiled and should not be installed afterwards

[07:15:36] <_habnabit> tdsmith, yes

[07:16:09] <tdsmith> _habnabit: thanks!

[09:16:47] <ysionneau> hi!

[09:17:02] <ysionneau> Is there a standard way of checking python version in setup.py (setuptools)?

[09:17:17] <ysionneau> If I want to say that you need at least Python 3.4.3 to run my project

[09:17:44] <ysionneau> I have this so far, http://pastebin.com/UK8bM0DM is that the common standard way? Or is there some cleaner way?

[10:59:29] <ronny> ysionneau: there is no good way to facilitate tests down to the patchlevle, in particular since wheel is important these days

[10:59:40] <ronny> (wheel install will not run setup install)

[11:00:55] <ysionneau> ronny: I'm not sure what you mean by "patchlevel" , but major/minor/micro seems enough for us

[11:02:52] <ronny> ysionneau: micro i meant

[11:10:17] <ysionneau> ronny: so there's no other way than what I'm doing?

[11:11:00] <dstufft> ysionneau: no, that's it currently.

[11:56:16] <ionelmc> ysionneau: why do you care about patch level anyway?

[12:01:33] <ronny> ionelmc: i suspect a bugfix is needed for his/her software to work

[12:01:59] <ionelmc> ronny: yeah i was curious what bug is that

[12:08:10] <ysionneau> ionelmc : some asyncio issues where fixed in 3.4.3

[13:55:55] <gthank> Any guesses as to why PyQT4 doesn't show up in the output of pip freeze/list despite it being installed?

[13:57:43] <gthank> To be clear: this isn't actually causing me personally any issues, but I was extremely surprised by the behavior, and don't see any immediate reason for this being the case.

[13:57:59] <dstufft> how was it installed

[13:59:45] <gthank> In my case? Almost certainly via a homebrew install of scipy

[14:00:06] <gthank> There's somebody over in #python that was having some sort of issue who installed it via the official Windows installers

[14:00:16] <dstufft> it mgiht not be dropping an egg-info or dist-info file if it's doing something custom-ish

[14:00:22] <dstufft> s/file/dir/

[14:00:35] <gthank> Ah, that's probably the reason

[14:00:41] <gthank> Let me double-check my dir

[14:00:54] <gthank> I only checked for __init__.py at first

[14:01:25] <gthank> Yep, no egg-info or dist-info

[14:01:59] <gthank> When are those required?

[14:02:43] <dstufft> anytime you want pip or setuptools to recognize something is installed

[14:03:57] <gthank> OK. I thought I was seeing some stuff show up as installed without those, but it's just a case mis-match causing jinja2 and Jinja2-FOO.egg-info to show up in different parts of the list

[14:04:00] <gthank> Thanks a ton, dstufft

[19:34:16] <gchristensen> Hi, I have a project named `probe` which depends on a package called `cfytools`. `cfytools` has a setup.py which declares requests>=2.7.0 as a dependency, and the `probe` package has a requirements.txt which declares "-e ." and "requests==0.4.3". when I `pip install -r requirements.txt` it ends up install requests 0.4.3 and makes no mention that the dependencies are not satisfiable. Is this a bug? it seems the

[19:34:19] <gchristensen> only way to safely upgrade a package is to completely delete the requirements.txt, install the new one, and regenerate. is this correct?

[19:38:03] <dstufft> gchristensen: It's https://github.com/pypa/pip/issues/988

[19:38:18] <dstufft> pip's "resolver" is very very simple- Basically it uses the very first instance of a specifier it finds

[19:39:34] <gchristensen> I see, so for deploying things to production, should we simply avoid a requirements.txt?

[19:50:33] <dstufft> gchristensen: or regenerate it

[20:19:34] <pjdelport> gchristensen: As far as I understand it, using -r <file> basically means "override whatever else is specified with these"

[20:22:13] <carljm> gchristensen: I would say you _should_ use a requirements.txt that exactly specifies all your dependencies for deployment (including dependencies-of-dependencies)

[20:22:41] <carljm> but you shouldn't assume that pip will catch conflicts for you (at least not currently); you should test your requirements.txt and make sure it results in a working environment before you deploy using it.

[20:23:18] <carljm> (even if pip were fixed to have a better resolver, that would still be true, as there are often incompatibilities in practice between versions of Python packages that aren't necessarily reflected in their dependency metadata)

[20:24:08] <gchristensen> we do both of those things now, I'm just questioning my own sanity now.

[20:41:55] <robertjw> I'm having some trouble trying to install pip on a system that has both 2.6 and 2.7 libraries. pip wants to use the 2.6 libraries and I'm looking for a way to install pip so that it recognizes the 2.7 libs instead.

[20:43:14] <robertjw> Using 'easy_install pip' results in "Installing pip2.6 script to /usr/bin"

[20:43:58] <aclark> robertjw: easy_install-2.7 pip

[20:48:35] <robertjw> good tip, I'll follow up in that direction, thanks

[22:54:01] <d6e> is there any way to make the index server specified in pip.conf a "trusted-host"?

[23:22:02] <d6e> nevermind

[23:22:32] <d6e> found this https://github.com/openstack-infra/system-config/blob/master/modules/openstack_project/files/pip.conf

Log file Viewer

Help | Karma | Search:

#pypa logs for Wednesday the 3rd of June, 2015