*.py packaging, again

Jacek Konieczny jajcus at jajcus.net
Thu Jul 14 09:44:01 CEST 2011

On Wed, Jul 13, 2011 at 03:07:07PM +0200, Jakub Bogusz wrote:
> I don't like the idea of __pycache__ not managed by rpm (or not
> maintained with rpm database in case of more robust post scripts)
> because of at least:
> - possible inconsistences (like leftovers in case of upgrade failures;
>   in such case it would be even possible that after installing another
>   version of package with *.py files having older date than pycache,
>   pycache won't be rebuilt)
> - more work needed to find package "owning" __pycache__/* files
> - one more place to hide some malicious code not detectable by rpm -Va

Ok, you may be right. But what than? We don't even have an idea how
should the proper rpm solution work and no volunteers to design and code
it. At the same time Python 3.2 is waiting for being included in PLD,
Python 3.3 is on its way and PyPy could be useful too, provided
compatible packages are available.

Maybe we should just start packing the *.py files together with the
compiled files for the python version they are built for? Yes, I know I
can start the old 'we don't package sources' flame war again, but '*.py'
files are not sources, they are the executable code. '*.pyc' and '*.pyo'
are just 'optimized versions' of those. And for Python 3.2 we have no
option – I have already started adding both *.py and __pycache__/* to
the python3 packages I have recently done.

For Python 2 (python-* packages), when including *.py:

We gain:
- ability to use the installed noarch packages by other Python 2.7
  implementations (like PyPy)
- easier debugging 
- no need to patch apps that look only for python code in '*.py' only

We lose:
- a little bit of the disk space
- some 'purity' some people see in not distributing 'sources'

For Python >= 3.2 (python3-* packages):

We gain:
- compatibility with the language

We lose:
- simplicity of the %files section (listing extra directories may make
  things a bit more complicated)
- some 'purity' some people see in not distributing 'sources'

In case some automated mechanism is provided, in the future, for keeping
the compiled python code files in the RPM database without listing them
in the spec files, we loose nothing by having the files there already
(by explicitly listing them in the specs).


More information about the pld-devel-en mailing list