python3.2+ compiled files

[Jeff Johnson]

On Apr 3, 2011, at 9:15 AM, Patryk Zawadzki wrote:

> On Sun, Apr 3, 2011 at 3:04 PM, Jacek Konieczny <jajcus at jajcus.net> wrote:
>> On Sun, Apr 03, 2011 at 02:38:49PM +0200, Patryk Zawadzki wrote:
>>> Except in Python you can execute/import .py files just fine. If the
>>> program is not closed source, .pyc/.pyo/__pycache__ are just an
>>> optimization detail. We could very well create them in %post.
>> That is a very bad idea. Bad things will happen if the package is
>> removed and *.py[o] stays (the module will still be visible to Python).
>> Best way to make sure 'compiled' files are gone when the package is gone
>> is to include them in the package.
> 
> We have %ghost and we can remove such files on uninstallation. My
> point is that .py[co] is how even more of an optimization detail than
> it was before. Can any other implementation of python handle
> __pycache__? What if two packages install a file to somedir/? Which
> gets to own __pycache__? Can python itself remove obsolete caches when
> politely asked? Can it keep the __pycache__ tree in a separate prefix
> instead of along the files?
> 

And not %ghost please: st->st_mode typing and other "useful" info is
lacking for paths marked %ghost.

(aside)
There's no reason whatsoever that %ghost-like cannot be extended
to include other info that is necessary.

I see a problem with /usr/bin/__pycache__/* and the rest of
the python litter on a file system. While __pycache__ subdirs "works" in python's
module trees, there will be a litter of __pycache__ subdirs on other
paths.

But can't a shadow tree (perhaps /var/cache/python/usr/bin/__pycache__/*?) be done?

Another alternative might be a python modules whose sole purpose
is/was to create a shadow tree within /usr/lib/python/X.Y/... for
use by python executables installed in /usr/bin etc ...

hth

73 de Jeff