[Josselin Mouette, 07.01.2008] > Let me guess: there is a templates.py containing the module, and a a > templates/ subdirectory containing templates?
yes, I renamed it to templates_dir. Yeah, I was thinking about moving it to /usr/share, but ... > Frankly, it is expected, when doing such horrible things, to hit > horrible bugs. Python templates, in a directory available to python, > that you don’t want available to the interpreter? Are upstream > developers mad or what? > > Python directories are meant to put python packages, not tons of data > and whatnot for the package, and it is a real shame there are facilities > in the language to help doing such stupid things. This data should have > been in /usr/share/something instead from the very beginning. this directory contains templates of... python modules, so I need to test it carefully before moving this dir to /usr/share/ > Given how namespace packages are implemented, you can’t disable them on > a per-package basis. What we could imagine is to ship e.g. a “.noinit” > file in directories in which you don’t want __init__.py to be created. > But this should be a workaround for buggy packages, not the default > behavior. > > Would that solution be sufficient for you? .noinit file in every directory? What if content of this dir will be copied recursively (at runtime) and these files will be copied as well? I want to avoid that. What about debian/pysupport_noinit_dirs (TODO: think about better file name ;) file? (with list of dirs and a mark if it should be applied recursively). I.e. something like: /usr/share/python-support/python-module/dir_1 /usr/share/python-support/python-module/dir_2/* the second one should not add __init__.py in f.e. /usr/share/python-support/python-module/dir_2/dir_3
