Hi, On 02/20/2017 08:26 AM, Richard Biener wrote:
On Fri, 17 Feb 2017, jan matejek wrote:
2. dropping .pyc and compiling on installation That's certainly possible (Debian does something of the sort) and has even some interesting advantages: it allows you to transparently support many different python versions simultaneously with just one package install. Of course, it would be a lot of work. Doing this manually in every package is not realistic, we'd need some sort of automation that does this for a package in a single macro, or maybe a "python-central" tool that you run against the filelist in %post, or something... You would also have to %ghost all the .pyc files, otherwise all you get is a big ugly mess of not-owned files. The singlespec macro set could help with this, possibly even creating the %post/%preun scriptlets and %ghost entries automatically in packages.
This requires further discussion on the tradeoffs, probably at least a rudimentary install time benchmark, but I'm not opposed to including something like this. I wonder whether python can place .pyc files in a cache location like /var/cache/python-$VER which we could then even prune off old unused entires. If this place is not writeable by the user, there's of course no way to do that. Thus the bytecode won't be cached. More specifically whether python knows that .pyc "depends" on .py and thus when .py is modified it will re-build the .pyc cache file? Simply by comparing timestamps, as already explained in other's mails.
Sebastian -- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers