Hi, and sorry for the delay. On lun, 2008-01-07 at 12:37 +0100, Piotr Ożarowski wrote: > > 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/
Frankly, this is their place. If they are templates, this shouldn’t make
anything fail. You can even use a symbolic link so that this is
transparent to the application — but not to python-support, which will
link to the link but happily ignore what’s behind it.
> > 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?
No, I mean creating a file like that:
/usr/share/python-support/crappy-package/templates/.noinit
Other directories don’t need it.
But frankly, I’d prefer to avoid that. This issue is really a symptom of
an upstream bug in your package, that you can easily work around by
moving the files to their correct place.
Cheers,
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
