On Fri, Feb 22, 2002 at 10:06:06PM +0100, Christian Kurz wrote: > On 22/02/02, Donovan Baarda wrote: > > First, remember that this tool is explicity for the subset of packages > > containing pure-python modules that work with multiple versions of Python. > > Well, but that's a good point for starting to change the setup and > handling of .pyo and .pyc files. If there's a new central solution using > python-register-package, I think we'll be able to find also a good > solution like this for packages which contain an executable python > script with addition .py files that contain used functions. So let's get > this sorted out and in place to get the rest also fixed.
I consider anything that results in .pyo and .pyc files to be a "pure-python module", that includes additional .py files containing used functions. These are distinct from compiled python extensions. My initial impression is that a large number of "python-foo" packages are either compiled extensions, or tied specificly to particular versions of python. BTW, the python-register-package tool in python-central requires/assumes that any multi-version compatible .py files that need to be compiled into .pyc and .pyo files are installed into /usr/lib/python/site-packages. I think this is a valid assumption, but does everyone agree? I know there are some out there that think we should be using /usr/share/python and /usr/share/pythonX.Y. Can someone confirm/deny that .pyc and .pyo files are truely platform independant? Are there any endian-ness issues? -- ---------------------------------------------------------------------- ABO: finger [EMAIL PROTECTED] for more info, including pgp key ----------------------------------------------------------------------