question on packaging of python applications
Hi, I recently created a debian file for my project (see http://subterfugue.org), and discovered just now why including .pyc and .pyo files directly doesn't work optimally. Looking at other packages which contain python code, it looks like there are several slightly different variations on how this is being done. There seem to differences in exactly which states (configure, etc) cause compilation, and which states, if any, cause removal of *.py[co] files. Is there any sort of policy for this? Or lacking that, is there a particular package I ought to use as a good model? Thanks, --Mike -- [O]ne of the features of the Internet [...] is that small groups of people can greatly disturb large organizations. --Charles C. Mann
Re: question on packaging of python applications
>I recently created a debian file for my project (see http://subterfugue.org), >and discovered just now why including .pyc and .pyo files directly doesn't >work optimally. Where is the problem? Python bytecode should be platform independent! So it is safe to include .pyc and .pyo files. There is no need to compile them at configure time. >Is there any sort of policy for this? Or lacking that, is there a particular >package I ought to use as a good model? I recommend the Distutils (included in Python 2.0 as a module). Then you can use "python setup.py install --root=`pwd`/debian/tmp" in your rules file and the .pyc and .pyo files are generated automatically. Look at my own program at http://linkchecker.sourceforge.net/ Bastian
Re: question on packaging of python applications
Bastian Kleineidam <[EMAIL PROTECTED]> writes: > >I recently created a debian file for my project (see http://subterfugue.org), > >and discovered just now why including .pyc and .pyo files directly doesn't > >work optimally. > Where is the problem? Python bytecode should be platform > independent! So it is safe to include .pyc and .pyo files. There is no > need to compile them at configure time. There is no need to include .pyc and .pyo in packages as python programs can work without at first use. Moreover, this makes packages bigger. That is why most of us prefer to follow Gregor Hoffleit's method (see postinst and prerm samples in /usr/share/doc/python-base) i.e py are compiled at postinst time and revoed at prerm time. > > >Is there any sort of policy for this? Or lacking that, is there a particular > >package I ought to use as a good model? > I recommend the Distutils (included in Python 2.0 as a module). At the moment, there exists a python-distutils package as Debian did not provide a version 2.0 yet. -- Jérôme Marant <[EMAIL PROTECTED]> http://jerome.marant.free.fr
Re: question on packaging of python applications
Bastian Kleineidam <[EMAIL PROTECTED]> writes: > >I recently created a debian file for my project (see http://subterfugue.org), > >and discovered just now why including .pyc and .pyo files directly doesn't > >work optimally. > Where is the problem? Python bytecode should be platform > independent! So it is safe to include .pyc and .pyo files. There is no > need to compile them at configure time. The problem is that in order to have the compiled versions used, they must be newer than the corresponding source (.py file). But if you just include them as files, they'll be unpacked with virtually identical but arbitrarily differing timestamps. So, for example, foo.pyc might be just slightly older than foo.py, in which case python will recompile foo.py on each and every load (since foo.pyc isn't writable by normal users). As for being platform independent, yes, this is true. I assume the reason for compiling, though, is to pick up and match the exact version of python that the user has on their machine (they might even have their own custom version). > >Is there any sort of policy for this? Or lacking that, is there a particular > >package I ought to use as a good model? > I recommend the Distutils (included in Python 2.0 as a module). > Then you can use "python setup.py install --root=`pwd`/debian/tmp" > in your rules file and the .pyc and .pyo files are generated > automatically. > Look at my own program at http://linkchecker.sourceforge.net/ Hmm. Well, I was under the impression that distutils didn't support debian. It doesn't really, but I see what you're doing. Unfortunately, my project isn't compatible with distutils because distutils assumes that all modules in the root package will be in the same directory (which isn't true for my project). Anyway, it seems like there ought to be a policy about installing or not installing the compiled files. Right now, to me, it looks like they should be generated at install time... --Mike -- [O]ne of the features of the Internet [...] is that small groups of people can greatly disturb large organizations. --Charles C. Mann
Re: question on packaging of python applications
[EMAIL PROTECTED] (Jérôme Marant) writes: > Bastian Kleineidam <[EMAIL PROTECTED]> writes: > > > >I recently created a debian file for my project (see > > >http://subterfugue.org), > > >and discovered just now why including .pyc and .pyo files directly doesn't > > >work optimally. > > Where is the problem? Python bytecode should be platform > > independent! So it is safe to include .pyc and .pyo files. There is no > > need to compile them at configure time. > There is no need to include .pyc and .pyo in packages as python programs > can work without at first use. Yes, but normal users typically cannot create .pyc files, of course. > Moreover, this makes packages bigger. Quite true. > That is why most of us prefer to follow Gregor Hoffleit's method > (see postinst and prerm samples in /usr/share/doc/python-base) > i.e py are compiled at postinst time and revoed at prerm time. Yes, most of the packages look like this. But as I mentioned, there are differences, and I wonder if some of the differences aren't subtle mistakes. --Mike -- [O]ne of the features of the Internet [...] is that small groups of people can greatly disturb large organizations. --Charles C. Mann
