PMXBOT Log file Viewer

Help | Karma | Search:

#pypa logs for Friday the 13th of March, 2015

(Back to #pypa overview) (Back to channel listing) (Animate logs)
[11:17:36] <ronny> dstufft: ping?
[12:37:55] <jluttine> hi! i have a problem: i have created a package X which depends on numpy, h5py and some other packages. when running "pip install X", the installation fails on h5py installation because "no module named numpy". why numpy isn't installed for h5py? is there any workaround i can do in my setup.py for X?
[12:38:35] <jluttine> i need "pip install X" to properly install the requirements..
[12:39:40] <jluttine> related: https://github.com/pypa/pip/issues/2478
[13:25:31] <jluttine> for instance: can i force the order in which install_requires packages are installed? if i just could force numpy to be installed before h5py, that might fix the problem.
[13:26:11] <jluttine> also, dropping numpy from my install_requires list might solve the problem, but i need to have it because i need to specify a minimum version for numpy
[16:16:43] <ronny> dstufft: ping?
[16:18:59] <dstufft> ronny: heya
[16:19:40] <ronny> dstufft: got some time to talk wrt the releasetool idea, i'd like to run it trough you sine i think you will be able to provide me with some insights i'd be missing otherwise
[16:20:58] <dstufft> ronny: sure
[16:21:41] <ronny> for that particular one i think voice would be most effective for communicating, whats your prefered method/tool?
[16:22:33] <dstufft> ronny: Uh, I don't care. but for voice give me a few
[16:29:18] <ronny> at least i suppose ^^ my phone has skype, hangouts and wlan
[16:34:27] <ronny> dstufft: do you actually have to create some working setup first?
[16:35:10] <dstufft> ronny: No, I'm just going over something ATM and voice requires more dedicated attention :) just finishing that up
[16:37:55] <dstufft> ronny: ok
[16:38:13] <dstufft> ronny: I don't know how to setup a hangout, but if you want to make one of those that's fine
[16:39:31] <ronny> dstufft: thats needs a browser plugin and/or something on the phone, what tools do you have/know for voice
[16:39:45] <dstufft> I have skype laying around here somewhere
[16:39:53] <dstufft> lemme see if I I remember my account
[16:41:13] <ronny> you havent done voice in quite a while, havent you ^^
[16:43:03] <dstufft> I do vidyo for work, but you can't get on that
[16:44:03] <ronny> that one looks powerfull ^^
[16:44:35] <dstufft> ronny: ok, my skype username is dstufft
[16:44:47] <apollo13> surprise :รพ
[16:44:49] <ronny> dstufft: they have a angouts extension ^^ does your work have that
[16:46:14] <dstufft> apollo13: I try to mix it up
[16:46:24] <dstufft> ronny: in our vidyo? no idea, I just use the vidyo app
[16:46:35] <ronny> i see
[16:47:00] <apollo13> fwiw, if you are just two people, try firefox hello
[16:47:04] <apollo13> works perfect imo
[16:47:24] <ronny> http://piratepad.net/Ovm8bJz6Oy
[17:52:15] <jezdez> ronny: oh boy
[17:52:23] <jezdez> you really wanna go that way?
[18:05:44] <ronny> jezdez: why?
[18:14:36] <_habnabit> ronny, why enforce crappy code layout?
[18:16:06] <ronny> _habnabit: why is having src crappy? not having it breaks various things
[18:16:17] <ronny> and creates various default mistakes
[18:16:19] <tos9> like what
[18:16:21] <doismellburning> what things?
[18:16:33] <tos9> (it breaks some things which are bad behavior of *other* tools certainly)
[18:17:14] <_habnabit> ronny, what tos9 said, and you're also enforcing moving tests out of the installed package
[18:17:16] <tos9> *enforcing* tests outside package is really really bad
[18:17:23] <tos9> without having that argument about which is right
[18:17:28] <tos9> certainly it's no *more* right
[18:17:40] <doismellburning> tos9: er, why is it really really bad?
[18:17:47] <tos9> doismellburning: Because it works only for py.test.
[18:17:49] <ronny> tos9: well, you cant sanely run tests against different installed versions without moving them out of the code tree
[18:17:55] <tos9> ronny: Sure you can.
[18:18:04] <tos9> Tests are code. This is the same argument we always have.
[18:18:11] <tos9> So if your tools is designed only for py.test users, fine.
[18:18:19] <doismellburning> tos9: er what?
[18:18:29] <tos9> But otherwise, you do that by running the test suites of each of your installed packages.
[18:18:33] <doismellburning> pretty sure I have most of my test code outside of the tree, and I've never used py.test
[18:18:33] <_habnabit> ronny, when would you want to run tests written for one version of a program against another version of the program?
[18:18:50] <tos9> doismellburning: Yeah sorry, it works for other test runners, but py.test is what generally *tells* people to do that
[18:18:52] <doismellburning> tos9: https://github.com/doismellburning/django12factor as a small example
[18:18:55] <doismellburning> tos9: oh right
[18:18:57] <tos9> doismellburning: (And to not make `tests` a package)
[18:19:00] <ronny> _habnabit: demonstrating failures against earlier versions and demonstrating regressions
[18:19:46] <ronny> also it prevents running tests against the source tree when in fact one wants to test a installed tree
[18:20:37] <doismellburning> tos9: as I say, never used py.test, but we do the "tests not in code tree" thing here lots to avoid packageyfaff
[18:20:43] <ronny> also develop installs are practically broken when one does not use src
[18:21:05] <tos9> ronny: that is a tox bug.
[18:21:08] <tos9> Not a problem with not having src.
[18:21:24] <doismellburning> develop installs?
[18:21:25] <ronny> tos9: its a setuptools/python path bug
[18:21:39] <tos9> ronny: How? I have no issue running tests against either source or install.
[18:22:20] <ronny> tos9: tox can run installed package tests jsut fine
[18:22:25] <tos9> ronny: It can, and does not by default.
[18:22:29] <tos9> Which is a bug IMO.
[18:22:49] <ronny> by defautl tox does nothing
[18:22:53] <ronny> you tell it
[18:22:55] <ronny> by design
[18:22:57] <tos9> But it seems like the layout you're choosing is specifically intending on entering in on this conversation again, so I guess we probably shouldn't object to this specifically.
[18:23:15] <tos9> ronny: Yes, but it's a tool, it should be helping people and preventing bad things.
[18:23:24] <tos9> Specifically, it should be making sure not to do that by default.
[18:23:42] <tos9> Not making people remember to chdir away in their tox.inis every time they write one.
[18:25:59] <ronny> tos9: tox is designed to supper different layouts without artifically limiting the user, and not part of the original argument ...
[18:26:23] <tos9> ronny: Yes I understand :) -- I am pointing out that what you said is a bad part of tox, not a bad part of not having src.
[18:26:32] <tos9> Which was what we meant before.
[18:27:04] <_habnabit> ronny, eh? how does separating tests help you with that
[18:27:05] <ronny> tos9: tox has nothing to do with it, tox is just victim if pythonpath messes due to setup.py develop being broken with non-src layouts
[18:27:19] <ronny> _habnabit: we are sidetracked atm
[18:27:27] <tos9> How is setup.py develop broken?
[18:27:52] <ronny> tos9: without src, it puts all of your code into sys.path
[18:28:20] <ronny> which includes breaking naespace packages and other fun ^^
[18:28:25] <ronny> *namespace
[18:30:33] <tos9> I don't use namespace packages, so I'm not sure I understand what you're referring to I guess.
[18:30:49] <tos9> You mean it puts the directory on sys.path, and that messes with other things in there that you didn't really mean to put there?
[18:32:26] <ronny> brb, telephone
[18:55:17] <ronny> will take longer
[19:14:45] <ionelmc> tos9: i have a write up here for all the argument for the `src` thing http://blog.ionelmc.ro/2014/05/25/python-packaging/
[19:18:06] <tos9> ionelmc: I can't read all of that right this minute, saving for later, but I read the first section
[19:18:19] <tos9> All of those are arguments I've heard before, and they all boil down to problems with a bunch of broken tools IMO.
[19:18:46] <tos9> I see you have a section on alternatives, so maybe you discuss that there.
[19:19:38] <ionelmc> tos9: well i'm going to get upset if you gonna reduce all that text to "tools are broken" ;-)
[19:20:56] <tos9> ionelmc: I'm not gonna reduce it :P, it's true, tools are broken and that's bad -- I just don't think we should develop new tools that enforce things we're doing because of broken tools. Not everyone uses those broken tools, and we can invent new ones that don't have the issues the current one does, but we'll be stuck with 8 billion src/ directories even once we do.
[19:21:55] <ionelmc> look, i'd be making the article shorter if i knew how
[19:22:13] <tos9> no no, I didn't mean your article is too long either :)
[19:22:42] <ionelmc> ad hominems and "crappy layout" straw-mans would be way shorter but I really wanna stay away from that sort of discourse
[19:23:22] <tos9> I think we got here just because ronny's tool was trying to enforce a package layout that I don't use (or well _habnabit said it first)
[19:27:55] <ronny> re
[19:29:09] <ronny> tos9: bascially setuptools namespace packages break in strange ways if you dont use a layout with src
[19:35:57] <_habnabit> ronny, go on
[20:03:20] <ronny> _habnabit: what should i go on with
[20:03:35] <_habnabit> 19:29:00 < ronny> tos9: bascially setuptools namespace packages break in strange ways if you dont use a layout with src
[20:04:18] <ronny> _habnabit: i dont understand the details myself, jsut that setuptools namespaces + develop installs break unless you add src
[20:13:07] <ronny> anyway, i dont see any value in puttung tests into the source tree, it makes installs larger and tempts distribution maintainers to strip them out
[20:14:18] <tos9> ronny: you understand at least that your argument isn't ocnvincing though?
[20:14:38] <tos9> regardless of who's actually correct.
[20:15:16] <ronny> tos9: well, oppinions tend to differ on that, its a topic where there is no good right/wrong
[20:15:24] <tos9> ronny: Right that's my point :)
[20:16:48] <ronny> i suspect other setups are reasonably simple to support, it will just need someone that cares and contributes
[20:17:43] <ronny> initially i will focus on what i know works from own experiences
[20:17:52] <ronny> making everyone happy from the get go is bound to fail
[20:18:18] <ronny> hmm
[20:18:53] <ronny> i still nee to figure a name tho, im still stuck in the biased ideas of releasetool and packaging, that just cannt work out ^^
[21:34:28] <dstufft> tos9: _habnabit fwiw we had to put pyca/cryptography into a src/ dir
[21:34:36] <_habnabit> dstufft, we talked about this before
[21:34:59] <_habnabit> dstufft, you said you didn't try the exact same combination of tools/options as i use to make it work without src/
[21:37:16] <dstufft> _habnabit: I lose tracks of conversations anymore :/ Just saying it's not unreasonable to have a src/ dir. but the way packaging is going people can make their own setuptools "replacement" on the developer side that does whatever they want
[21:44:53] <_habnabit> dstufft, http://paste.pound-python.org/raw/CCoG8MgKunzRh2iT3mUl/
[21:48:33] <dstufft> _habnabit: going by the last thing said there, I'd probably still put things in a src/ dir. I don't like installing tests *shrug*
[21:48:53] <_habnabit> dstufft, i don't like not installing tests
[21:49:33] <dstufft> _habnabit: well you're allowed :) It's not like ronny's thing can prevent you from doing that either. It won't know that foo/tests/test_thing.py is a test module not part of your program
[21:49:56] <_habnabit> dstufft, depends on the implementation
[21:52:47] <dstufft> _habnabit: I'm having a hard time imagining an implementation that disallowed that, unless it disallowed anything that happened to look like it might be tests.. which seems silly
[21:54:06] <_habnabit> dstufft, i could easily see someone 'well-meaning' making that print a warning every time
[21:54:28] <_habnabit> dstufft, alternately it might have a `setup.py test` equivalent that depends on that location for tests
[21:57:18] <dstufft> setup.py test considered harmful anyways ;)
[21:57:41] <_habnabit> heh
[21:58:06] <_habnabit> dstufft, if we're going to imagine new infrastructure, why not have an automated/standardized way of running your tests?
[21:58:24] <dstufft> but yea, that's possible, though in general the point doesn't really matter, because we're never going to get into a situation where you *must* use a particular tool again if I can help it
[21:58:48] <dstufft> _habnabit: we will, it just won't be setup.py test because it's bad (well probably there will be a shim but w/e)
[23:09:37] <fletchowns> how come `pip uninstall x` doesn't remove ~/.virtualenvs/my-env/src/x ?
[23:09:44] <fletchowns> it was installed using `pip install -e git@whatever`