[arch-dev-public] Python packaging policy
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. Thanks, Allan
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 Allan
On Thu, Dec 18, 2008 at 6:34 AM, Allan McRae <allan@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) ?
Aaron Griffin wrote:
On Thu, Dec 18, 2008 at 6:34 AM, Allan McRae <allan@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
On Thu, Dec 18, 2008 at 7:28 PM, Allan McRae <allan@archlinux.org> wrote:
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.
The problem with option #2 is that those files are no longer tracked by pacman. Removing the package could still result in removal of those files, but it gets very ugly... it'd be nice if these files were tracked by pacman.
On Fri, Dec 19, 2008 at 12:59 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, Dec 18, 2008 at 7:28 PM, Allan McRae <allan@archlinux.org> wrote:
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.
The problem with option #2 is that those files are no longer tracked by pacman. Removing the package could still result in removal of those files, but it gets very ugly... it'd be nice if these files were tracked by pacman.
OMG you said that already... sigh
participants (2)
-
Aaron Griffin
-
Allan McRae