Re: policy 2.3 para 2
On Sat, Feb 23, 2002 at 10:11:41PM +, Julian Gilbey wrote: On Sat, Feb 23, 2002 at 12:45:07PM +1100, Donovan Baarda wrote: It may be that as python is simpler, we can simply have a script in a python-common package which does something like (pardon me if I get [... sample scripts...] It's funny how minds think alike... did you write these before or after python-central, or did you base them on it. There is a lot in common :-) What's python-central? A suggested way for pure-python modules to support multiple versions of Python, based on the emac'en registry idea. It is implemented as a package called python-central. http://people.debian.org/~calvin/python-central/ (That may answer your question 8-) maybe he grabbed ideas from your post then :-) -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: policy 2.3 para 2
On Tue, Feb 12, 2002 at 10:17:16PM +, Julian Gilbey wrote:
On Mon, Feb 11, 2002 at 10:19:56PM +1100, Donovan Baarda wrote:
Why not take the emacsen-common method and code and use this for
python? It probably won't work for C-extension modules, but it could
make life easier for pure Python ones.
Just a thought; since we already have a database of packages in the form of
the dpkg database, is it possible to do something simple using it instead of
introducing some other database? As an example, can a python package call
dpkg-reconfigure for all installed packages that depend on python in
its postinst script?
You have two cases to consider:
(1) Installing/removing pythonX.Y package
(2) Installing/removing a python-depending package
Your suggestion will perhaps work for the former but not for the
latter: every python package which wishes to use this scheme will have
to have postinst code anyway.
[...]
This was just an off-the cuff suggestion intended to prompt some thinking...
Since doing some more thinking about it, I think I can see a way that it can
be done for both cases, but not easily or efficiently.
The trick is to have multi-version python modules have Depends:
(pythonX.Y | pythonX.Y+1 | ...) including every version of python they are
compatible with. This can be used to indicate what versions of python the
module should be sym-linked and compiled for when/if they are installed.
When a new python-foo is installed/removed, it's .post(inst/rm) script
calles a python-central style register-python-package to
symlink+compile/remove its .py's for all the currently installed versions of
pythonX.Y.
When a new pythonX.Y is installed/removed, it must find every package with a
pythonX.Y dependancy and symlink+compile/remove all files matching
/usr/lib/python/site-packages/*.py.
Perhaps something like;
# get_modules python version
# return all packages that have multi-version python modules that work for
# the specified python version
get_modules() {
VER=$1
RET=
for p in dpkg -S /usr/lib/python/site-packages | sed 's#,##g; s#:.*$##'; do
if `dpkg -s $p | grep ^Depends:.*python$VER /dev/null 21`; then
RET=$RET $p
fi
done
}
It may be that as python is simpler, we can simply have a script in a
python-common package which does something like (pardon me if I get
[... sample scripts...]
It's funny how minds think alike... did you write these before or after
python-central, or did you base them on it. There is a lot in common :-)
--
--
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
--
Re: policy 2.3 para 2
On Mon, Feb 11, 2002 at 10:19:56PM +1100, Donovan Baarda wrote:
Why not take the emacsen-common method and code and use this for
python? It probably won't work for C-extension modules, but it could
make life easier for pure Python ones.
Just a thought; since we already have a database of packages in the form of
the dpkg database, is it possible to do something simple using it instead of
introducing some other database? As an example, can a python package call
dpkg-reconfigure for all installed packages that depend on python in
its postinst script?
You have two cases to consider:
(1) Installing/removing pythonX.Y package
(2) Installing/removing a python-depending package
Your suggestion will perhaps work for the former but not for the
latter: every python package which wishes to use this scheme will have
to have postinst code anyway.
It may be that as python is simpler, we can simply have a script in a
python-common package which does something like (pardon me if I get
the python a little wrong) -- this could be rewritten in python, of
course, although there's a little question of which python version
would be used
#! /bin/sh
Check to see whether there are any arguments saying to limit the
versions of python used or something similar
while [ $# -gt 0]; do
for pyth in /usr/bin/python[12].[0-9]; do
cd /usr/lib/`basename $pyth`
ln -s ../python-common/$1 .
$pyth -c import py_compile; py_compile.compile('$1');
py_compile.compile('$1','${1}o');
done
done
and a similar one for a package removal. Then on installation, a
python-module providing package could say in its postinst:
debian-python-compile foo.py bar.py wibble.py wobble.py
and install these modules into /usr/lib/python-common.
Or alternatively, just install them all into /usr/lib/python-common
and run python-update-install, which is essentially the same as the
above but doesn't take filename arguments and does the following
instead:
for pyth in /usr/bin/python[12].[0-9]; do
cd /usr/lib/`basename $pyth`
for module in /usr/lib/python-common/*.py; do
module=`basename $module`
if [ -L $module ]; then continue; fi
ln -s ../python-common/$module .
$pyth -c import py_compile; py_compile.compile('$module');
py_compile.compile('$module','${module}o');
done
done
However, that doesn't handle the case of removing packages. This
could be done using dpkg as you suggest: in the prerm, call
python-update-remove $pkg, and this does the following:
for pyth in /usr/bin/python[12].[0-9]; do
cd /usr/lib/`basename $pyth`
for module in dpkg -L $pkg | grep '^/usr/lib/python-common/.*\.py$'; do
module=`basename $module`
if [ -L $module ]; then
rm -f $module ${module}c ${module}o
fi
done
done
Now that's seriously easier than the emacsen-common solution, and is
possibly adequate for this situation.
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer
Queen Mary, Univ. of London see http://people.debian.org/~jdg/
http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/
Visit http://www.thehungersite.com/ to help feed the hungry
Re: policy 2.3 para 2
On Sat, Feb 09, 2002 at 07:41:31PM +, Julian Gilbey wrote: I have a suggestion, which may already have been thought of. For Python Policy 2.2.3, see http://lists.debian.org/debian-python/2002/debian-python-200201/msg00019.html I am working on this. I have the previous version online at http://people.debian.org/~calvin/purepython/ which uses debhelper scripts. Indeed this weekend I have been working on the new version, which is similar to emacsen-common (per-package DB entries etc.). I still have to test the scripts a little, so expect them to be online in the next 2-3 days. Why not take the emacsen-common method and code and use this for python? It probably won't work for C-extension modules, but it could make life easier for pure Python ones. I have looked into emacsen-common scripts, but I dont like programming in Perl, its a pain for me. Anyway it would be an offense if a Python-related package was written in Perl :) Greetings, Bastian pgpRNCkpf4njd.pgp Description: PGP signature
Re: policy 2.3 para 2
On Mon, Feb 11, 2002 at 11:28:50AM +0100, Bastian Kleineidam wrote: On Sat, Feb 09, 2002 at 07:41:31PM +, Julian Gilbey wrote: I have a suggestion, which may already have been thought of. For Python Policy 2.2.3, see http://lists.debian.org/debian-python/2002/debian-python-200201/msg00019.html I am working on this. I have the previous version online at http://people.debian.org/~calvin/purepython/ which uses debhelper scripts. Indeed this weekend I have been working on the new version, which is similar to emacsen-common (per-package DB entries etc.). I still have to test the scripts a little, so expect them to be online in the next 2-3 days. Super! I'll check it out when I have a moment. Why not take the emacsen-common method and code and use this for python? It probably won't work for C-extension modules, but it could make life easier for pure Python ones. I have looked into emacsen-common scripts, but I dont like programming in Perl, its a pain for me. Anyway it would be an offense if a Python-related package was written in Perl :) But of course! However, once it's translated into a sensible language, the principles should be fine ;-) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: policy 2.3 para 2
On Mon, Feb 11, 2002 at 11:28:50AM +0100, Bastian Kleineidam wrote: On Sat, Feb 09, 2002 at 07:41:31PM +, Julian Gilbey wrote: I have a suggestion, which may already have been thought of. For Python Policy 2.2.3, see http://lists.debian.org/debian-python/2002/debian-python-200201/msg00019.html I am working on this. I have the previous version online at http://people.debian.org/~calvin/purepython/ which uses debhelper scripts. I'm probably going to have a look at these soon and hope to give some input... Indeed this weekend I have been working on the new version, which is similar to emacsen-common (per-package DB entries etc.). I still have to test the scripts a little, so expect them to be online in the next 2-3 days. Why not take the emacsen-common method and code and use this for python? It probably won't work for C-extension modules, but it could make life easier for pure Python ones. Just a thought; since we already have a database of packages in the form of the dpkg database, is it possible to do something simple using it instead of introducing some other database? As an example, can a python package call dpkg-reconfigure for all installed packages that depend on python in its postinst script? -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: policy 2.3 para 2
On Sun, Feb 10, 2002 at 02:08:56PM +1100, Donovan Baarda wrote: On Sat, Feb 09, 2002 at 07:41:31PM +, Julian Gilbey wrote: I have a suggestion, which may already have been thought of. Need: a python-module (pure Python) providing package should provide byte-compiled versions for all installed python versions (as long as there are no version dependency issues) Actually, it is slightly more complex than this. For starters, forgetting that not all python modules are compatible with all versions of python, there is a second need; Not a problem. Need-2: installing a new version of Python should byte-compile all pre-installed Python modules for the newly installed Python version. That's the whole cleverness of the emacsen solution -- see below. This makes it a bit tricky because it's hard to know where the compile all for all scripts should go; in the versioned Python packages, in the Python default wrapper, or in the modules themselves. The moment you think it's obvious, you dig deeper and find it introduces some dependancy nastys. Quite -- but it's really good that the emacsen team have already solved this problem, so the python team doesn't have to reinvent the wheel. I'm not 100% sure of the details of the emacsen approach, but doesn't it use some sort of module-registration database? I can't help but think that it's a bit sad that you need to introduce _another_ database of installed stuff when you already have the dpkg database. However, perhaps that's the only way to get a truely perfect solution. Yes, emacsen-common reads a database of install/remove command files. See the /usr/lib/emacsen-common directory. It allows the packages to be a little bit clever for a relatively small maintainer cost, as the extra files are mostly boilerplate. This allows installing/removing emacs packages to be performed orthogonally to installing/removing different versions of emacs, and means that any version-independent emacs packages can work with all installed emacsen without having to be aware of which particular ones are installed, and without having to have a separate version for each emacs package. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: policy 2.3 para 2
On Sat, Feb 09, 2002 at 07:41:31PM +, Julian Gilbey wrote: I have a suggestion, which may already have been thought of. Need: a python-module (pure Python) providing package should provide byte-compiled versions for all installed python versions (as long as there are no version dependency issues) Actually, it is slightly more complex than this. For starters, forgetting that not all python modules are compatible with all versions of python, there is a second need; Need-2: installing a new version of Python should byte-compile all pre-installed Python modules for the newly installed Python version. This makes it a bit tricky because it's hard to know where the compile all for all scripts should go; in the versioned Python packages, in the Python default wrapper, or in the modules themselves. The moment you think it's obvious, you dig deeper and find it introduces some dependancy nastys. Parallel: an emacs-module providing package should provide byte-compiled versions for all installed emacs versions (as long as there are no version dependency issues) Why not take the emacsen-common method and code and use this for python? It probably won't work for C-extension modules, but it could make life easier for pure Python ones. I'm not 100% sure of the details of the emacsen approach, but doesn't it use some sort of module-registration database? I can't help but think that it's a bit sad that you need to introduce _another_ database of installed stuff when you already have the dpkg database. However, perhaps that's the only way to get a truely perfect solution. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
