Log file Viewer

[08:29:30] <dzen> hello

[08:29:57] <dzen> is this the nomminal way to declare specific python requirements in a project ?

[08:29:57] <dzen> https://bitbucket.org/pypa/wheel/src/79e669d9f170f5c653c674ac5177419580595d62/setup.py?at=default#cl-41

[10:57:03] <Ivo> dzen: not exactly sure what you mean

[10:57:33] <Ivo> dzen: to refer to specific requirements use install_requires (wheel doesn't have any)

[11:13:59] <dzen> but to require some dependencies depending (hehe) on the python version

[11:14:09] <dzen> but something that won't be dynamic

[11:15:46] <mgedmin> you can use tox to verify if this works

[11:15:59] <mgedmin> I've never seen extras_require={':python_version=...': [...]} before

[11:16:36] <mgedmin> I've seen people do install_requires=[...] + (['argparse'] if sys.version_info[:2] < (2, 7) else [])

[11:16:52] <mgedmin> (which implies that you cannot create a universal wheel out of this package!)

[11:17:40] <mgedmin> and there's a way of overriding the requirements in setup.cfg where you can use PEP-xxx conditionals

[11:17:50] <mgedmin> but I don't remember the syntax, and it sucks to specify the deps twice

[11:18:20] <mgedmin> (because this overriding is for the wheel only)

[11:18:38] <mgedmin> dstufft once told me in a tweet how to do that, but tweets are hard to find :/

[11:35:24] <dzen> it seems that pip does not honors this

[11:37:06] <mgedmin> lol: bin/pip2.7 --version

[11:37:06] <mgedmin> pip 1.5.4 from /var/lib/jenkins/jobs/wheelwright/workspace/local/lib/python3.4/site-packages (python 3.4)

[11:37:46] <mgedmin> and here I thought I could have pip for both 2.7 and 3.4 in a single virtualenv

[11:40:02] <dzen> can't wait the pep 426 to be valitdated :p

[13:12:05] <houms> good day, I am trying to build rpm of python application, and am having issues with installing scipy. the spec file has a pip command that fetches a number of modules, and only scipy seems to be an issue

[13:23:06] <Ivo> numpy & scipy aren't really built to be fetchable by pip

[13:24:14] <houms> Ivo not sure I follow, is there another recommended method to obtain scipy? numpy seems to install fine with pip

[13:25:51] <houms> Thanks for your insight nonetheless

[13:27:32] <Ivo> houms: it would be great if you could expand upon 'am having issues with installing scipy'. Thats an extremely nebulous problem description

[13:28:00] <Ivo> I have to be a wizard to be able to help you out with that

[13:32:55] <mgedmin> aren't there rpms of scipy already? debian has debs of it

[13:36:24] <Ivo> houms: you can build the rpm then use rpm tools (whatever they are) to manually add the dependency

[13:36:25] <houms> it says failed with error code 1 Ivo

[13:36:39] <houms> so instead just include a rpm version of scipy?

[13:36:44] <houms> that makes sense thanks

[13:36:59] <Ivo> well use fedora's name for it, or smth

[13:37:08] <Ivo> I can't say I'm an expert on rpm sorry

[18:27:00] <davidovich> jaraco: I have posted a small project to demonstrate setup develop.py failure on windows. Do you think this could be included in the tests ?

[18:42:12] <jaraco> davidovich, possibly.

[18:43:22] <jaraco> If you would like to write up a ticket describing the problem and failure, that would be helpful. If you want to additionally put together a pull request with a failing test, that would be even better.

[18:44:54] <davidovich_> jaraco, can you provide guidance ? And how do we fix the bug ? :-)

[18:45:28] <davidovich_> !logs

[18:45:28] <pmxbot> http://chat-logs.dcpython.org/channel/pypa

[18:46:06] <jaraco> davidovich_, possibly. I'll work on it as time permits. I put priority on pull requests over bug reports.

[18:46:50] <jaraco> But I also put priority on regressions over new features, so if it's something that's been a recent regression, I'll take a look at it sooner.

[18:47:58] <davidovich_> jaraco, but as my pull request https://bitbucket.org/pypa/setuptools/pull-request/60/fix-regression-in-issue-218/diff was rejected, what would be the path forward ?

[18:49:40] <jaraco> davidovich_, so that issue in particular, https://bitbucket.org/pypa/setuptools/issue/210/on-windows-binary-files-specified-as is a complicated one

[18:51:11] <jaraco> I understand the problem, but I don't have a good solution.

[18:51:54] <jaraco> I suspect that will pull request #60, other things would break.

[18:52:16] <jaraco> The interfaces aren't well defined, but where they are defined, they imply that arbitrary binaries aren't allowed as 'scripts'

[18:53:56] <jaraco> I want to take some time and make sure that create the appropriate interfaces such that it's well-defined what the expectations are.

[18:54:14] <jaraco> (for the 'develop' command as well as the underlying apis)

[18:54:45] <davidovich_> I tried to limit the changes after my initial naive approach failed. I essentially do what was there before, but favor binary opening, and then falling back to text if the script is indeed a text file. How can we test this more in the wild without breaking everyone?

[18:55:31] <jaraco> davidovich_, we can't really, except to start to defined the interfaces explicitly and communicate the changes well.

[18:55:36] <jaraco> *define

[18:56:07] <jaraco> Doug Hellmann has started work on some integration tests.

[18:56:14] <jaraco> So something like that might help.

[18:56:37] <davidovich_> Is it ready for use yet ?

[18:57:09] <jaraco> The integration tests are now included in the test suite, but 3/4 fail, so they've been marked as xfail.

[18:57:16] <jaraco> (expected fail)

[18:57:41] <jaraco> And actually, the fourth fails on Windows now.

[18:57:57] <jaraco> (due to the failure to delete a directory that's in use)

[18:58:21] <davidovich_> (oh I love windows) sigh

[18:59:20] <davidovich_> would https://github.com/davidovich/develop_breakage_on_windows fit as an integration test (that would fail).

[19:00:37] <davidovich_> I am pretty sure that the scripts usage I expose is pretty common. The intent is to place *things* in the Scripts directory (or bin on nix).

[19:09:00] <davidovich_> jaraco, on the otherhand, are you aware of an alternative way to copy binaries to the Scripts folder?

[19:09:45] <jaraco> davidovich_, I'm not.

[19:10:38] <jaraco> I'm almost inclined to think that that should be a PEP - to support arbitrary binaries as scripts. I know there's already some resistance to the concept, so it's worth getting some community support behind it.

[19:12:16] <jaraco> As for the integration test, I wouldn't mind if you added something to capture the failure/expectation.

[20:58:55] <davidovich_> jaraco, can I add a fixture resemblling https://github.com/davidovich/develop_breakage_on_windows inside the tests folder and call that from test_develop.py ?

[21:00:12] <jaraco> davidovich_, yes.

[21:02:18] <jaraco> davidovich_, keep in mind that test_develop.py is much older code than test_integration.py, but that the techniques in test_integration.py are preferred (py.test).

[21:02:47] <davidovich_> jaraco, I am not sure how to actually import the newly installed package in this environment. The current tests do not execute anything, but merely evaluate scripts presence.