[arch-dev-public] Python packaging policy

[Allan McRae]

Aaron Griffin wrote:
> On Thu, Dec 18, 2008 at 6:34 AM, Allan McRae <allan at archlinux.org> wrote:
>   
>> Allan McRae wrote:
>>     
>>> Hi all,
>>>
>>> A few recent bugs have highlighted issues with how we deal with compiled
>>> versions (.pyo/.pyc) of python (.py) files.    We should probably make a
>>> policy on how these should be handled during packaging.
>>> Given I am the python maintainer, I suppose I should be doing this, but I
>>> am wanting to do some more makepkg/pacman stuff so it would be good if
>>> someone else wants to take the lead on this.
>>>
>>> Here is a couple of policies from other distros
>>> Debian: http://www.debian.org/doc/packaging-manuals/python-policy/
>>> Fedora: https://fedoraproject.org/wiki/Packaging/Python
>>>
>>> If someone (not necessarily a dev) wants to help out with this, then it
>>> would be much appreciated.
>>>       
>> And given I have already been asked twice what the best way to start this
>> is, here goes a wiki page to collect ideas on this:
>> http://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy
>>     
>
> I wish I had something to help here. Do you have anything in mind as
> to how we will actually deal with pyc files on an upgrade (i.e. 2.5 to
> 2.6) ?
>   

Well, the options I see are
1) .pyc/.pyo files are created as part of packaging.  That way we just 
rebuild the package if needed during an upgrade.
2) .pyc/.pyo files are recreated on python/package update.  So, we would 
have a pre_update script that finds all the .pyc/.pyo files, deletes 
them and a post_update script that rebuilds them.  In this option, it 
would be better if .pyc/.pyo files were not part of a package as I don't 
like one package touching another packages files.

I'm heavily leaning towards #1 as I don't like having files on my root 
partition that are not controlled by pacman.  However, that can lead to 
a lot of conflicts during upgrades in the short term...

I haven't thought about this any further than that at the moment.

Allan