Log file Viewer

[03:05:10] <njs> natefoo: yeah, I'd build a modern libpq and then use that

[03:05:44] <njs> natefoo: that's probably what I'd do for pretty much any dependencies, honestly -- CentOS 5 is fairly weird and old :-)

[18:42:29] <ceridwen> In reference to my previous question: apparently MANIFEST.in doesn't affect installs, so I need to use package_data or data_files instead. I'm currently trying to get package_data working, but now I don't know how to get the right layout. My current directory layout looks like:

[18:42:37] <ceridwen> package/

[18:42:37] <ceridwen> actual_library/

[18:42:37] <ceridwen> __init__.py

[18:42:37] <ceridwen> broken_files/

[18:42:37] <ceridwen> __init__.py

[18:43:06] <ceridwen> That's the repository. There's no reason the broken_files need an __init__.py except that package_data doesn't work without it, AFAICT.

[18:44:47] <ceridwen> With "package_data = {<this_doesn't_seem_to_matter>: <paths_to_broken_files_relative_to_repository_root>}" in setup.py, I end up with the following directory structure in the virtualenv:

[18:45:31] <ceridwen> lib/

[18:45:31] <ceridwen> pythonX.Y/

[18:45:31] <ceridwen> site_packages/

[18:45:31] <ceridwen> actual_library/

[18:45:31] <ceridwen> broken_files/

[18:45:50] <ceridwen> I want the following structure instead:

[18:46:14] <ceridwen> lib/

[18:46:14] <ceridwen> pythonX.Y/

[18:46:14] <ceridwen> site_packages/

[18:46:15] <ceridwen> package/

[18:46:15] <ceridwen> actual_library/

[18:46:15] <ceridwen> broken_files/

[18:47:06] <tdsmith> sounds like package/ needs to be a package with a __init__.py

[18:47:18] <ceridwen> Is there any way to make that work? Note that the broken_files can't be inside actual_library and they can't be both subpackages of another package, because at that point tools will conclude they're all part of the same package and crash.

[18:59:32] <ceridwen> tdsmith, That sounds like the answer is, "No," because they both have to be subpackages of another package.

[19:02:30] <tdsmith> i think broken_files doesn't need to be a subpackage

[19:02:46] <tdsmith> if package is a package they can just be package_data for package

[19:03:40] <ceridwen> Okay, I'll try that.

[19:06:36] <ceridwen> I'm not even sure that will work, though, because I think the basic problem is that the tools process all Python files recursively in subdirectories of any Python package, so if setuptools requires that the data files be in a package too, that means there's a basic irresolvable conflict: if setuptools is willing to install them, the tools can find them and crash.

[21:02:22] <ionelmc> ceridwen: Dont forget include_package_data

[21:08:07] <tdsmith> ionelmc: when is that necessary?

[21:09:36] <ionelmc> When you don't wanna use the hardtouse package_data or data_files

[21:09:44] <ionelmc> It's more DRY

[21:10:29] <tdsmith> oh, so it's an alternative to speccing it manually, gotcha

[21:10:42] <tdsmith> does that draw from MANIFEST.in?

[21:10:51] <ionelmc> Yeah

[22:52:17] <ceridwen> ionelmc, I have include_package_data = True in my setup.py and graft broken_files in MANIFEST.in, but pip install package/ into a virtualenv never installs those files, so I'm having to use package_data. (I would definitely prefer not to.) I may end up having to use data_files, but I really don't want to because that requires explicitly spelling out all the possible directory configurations across multiple platforms.

[22:55:52] <ceridwen> Either that or this hideous hack, http://stackoverflow.com/a/26533921/3857947, which is frankly looking appealing at this point.