[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..
[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: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
[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: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
[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)
[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: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: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: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`