Re: Python versions and bytecode
On Wed, Mar 06, 2002 at 10:38:22AM +0100, Josselin Mouette wrote:
> le mer 06-03-2002 ? 01:33, dman a ?crit :
>
> > | as I'm currently packaging solarwolf, I have a question about python
> > | bytecode. I have put the .py files used by the game in
> > | /usr/lib/games/solarwolf/ and I compile them in postinst with
> > | compileall.py. The question is : will the generated .pyc and .pyo files
> > | still work if the major python version changes ?
> >
> > No. The bytecodes change when the developers feel like it (more or
> > less). That interface is not constant between even "minor" version
> > changes.
>
> Okay. So what is the preferred way to be sure that the bytecode for this
> game always corresponds to the current python version ?
Currently, you have the following options;
1) Use "Depends: python2.1" and release a new package when you want to use a
new version of python. This means you package will not break when the
default python changes to a new version, but it will require a "legacy
version" when this happens, untill you upgrade it.
2) Use "Depends: python (>=2.1), python (<<2.2)", and release a new version
when the default python changes version. This means the package will break
when the default python changes to a new version, requiring you to upgrade
your package, but it will never require a "legacy" version to be installed.
3) Use "Depends: python (>=2.1)", and tell everyone they must run
"dpkg-reconfigure <yourpackage>" after every default python upgrade. This
means you package will not break after default python upgrades and will
never depend on a "legacy" version, but the dpkg-reconfigure is necisary to
re-compile everything for the new version of python. Note that if python is
upgraded to a version that doesn't work for your package, this alternative
will not flag the problem. Instead you will get bug-reports from end users.
You can indicate an upper version limit if you want to package to break
beyond a certain version.
The python-central option, when/if it becomes accepted, would allow you to
do the following;
4) Use "Depends: python2.1 | python2.2, python-central", and it would
automaticly compile your package for any installed versions of python
between 2.1 to 2.2. This means your package will be automaticly compiled
when python is upgraded, and will also work for any of the specified legacy
versions. This would require you to put all *.py files into
/usr/lib/python/site-packages/<yourpackage>/ and add a "register-python
<yourpackage>" to it's postinst.
The details of python-central are still being nutted out. Your case raises
the interesting problem of "solarwolf" modules being compiled for all
compatible installed pythonX.Y's, but only using "#!/usr/bin/python" in the
main script. This is something I hadn't considered yet.
This suggests that python-central supporting "Depends: python (>=2.1),
python (<<2.3)" style specifications is a good idea at least in this case. I
was originaly against this, favoring "Depends: python2.1 | python2.2"
specifications because it allows legacy support. In your case the legacy
support this buys you would be broken by the "#!/usr/bin/python" on the main
script.
I'm starting to think python-central needs to support both dependancy
methods. A "Depends: python2.1 | python2.2" can be used to allow modules to
support multiple installed pythonX.Y's. A "Depends: python (>=2.1), python
(<<2.3)" can be used to indicate script support for the default python only,
but over a range of versions. It all gets trickier :-)
--
----------------------------------------------------------------------
ABO: finger abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Reply to: