Re: multiple pythons and the default
On Sat May 6 2006 06:55, Josselin Mouette wrote:
> Le samedi 06 mai 2006 à 04:29 -0600, Bruce Sass a écrit :
> > Is it unreasonable to want to install a module package which should work
> > with any Python and have *.pyc's automatically compiled for an
> > interpreter which lives in /usr/local/bin, or install a local
> > interpreter and have Debian attempt to compile all the installed
> > modules for it, have a local module compiled for packaged interpreters?
>
> I think this is unreasonable, yes. While we can maintain a list of
> python versions packaged for Debian and ensure they are all working
> correctly with e.g. python-support, trying to detect other versions and
> to compile modules for them would be too much error-prone. I have too
> much background of incomprehensible bugs that turned out to be caused by
> a user installing broken stuff in /usr/local.
I've broken stuff myself by installing into /usr/local, doesn't mean I'll
stop using it or discourage others... that may even be a reason to provide
some support for locally installed interpreters, one or two less things to
break.
> > ...and of course commenting. I have this picture in my head of a
> > Debian-Python infrastructure that has no pythonX.Y-module packages
> > because everything is automatically compiled for all available
> > interpreters. The "default python" would just happen to be the one
> > python-minimal is a subset of (which may well be an arbitrary choice)
> > and if an admin wants to use an alternate (maybe even local) Python as
> > the default they should be able to do so simply by providing the
> > equivalent of python-minimal for the new default interpreter
> > (necessarily tweaking any infrastructure code using non-portable
> > python, which would be a good thing).
>
> This is what python-support tries to achieve. However this is only
> possible for modules written in python. Modules written in C need to be
> built for every python version they support.
Of course, I was thinking about byte-compiling *.py's only.
With that in mind, is detecting and compiling for other interpreters still
much too error prone?
- find a bin/pythonX.Y
- check for the expected supporting dirs
If you can do those two things then it should be safe to assume there is a
pythonX.Y available, and the only difference between compiling for local
and packaged interpreters would be the paths.
I wouldn't expect snooping around the system to be the primary means of
building and maintaining a list of interpreters, although it could be
useful for sanity checking and perhaps initializing the list.
I do think that a packaged interpreter should tell the infrastructure when
it is installed and removed, the infrastructure should keep track of the
interpreters it knows about and do sanity checks on their infrastructure.
An admin should be able to register a local interpreter via the same
mechanism, and if its infrastructure passes the sanity check it should also
automatically get modules expected to work with any Python... whether those
modules actually work or not will be up to the admin to sort out (so, ya,
I guess you'd still get some incomprehensible looking bug reports, but,
since local modules and interpreters would be more visible, maybe those
reports wouldn't be quite so baffling).
> > My motivation for thinking along these lines is the realization that
> > large chunks of the current Python Policy could be removed if 2.5 was
> > implemented in such a way as to make pythonX.Y-anything unnecessary.
>
> The python policy surely needs work. I wish I had more time to work on
> it, and still hope to bring up a new draft soon, but everyone is free to
> work on it as well.
I also keep finding myself short on time, the good news is that I don't
think we are very far apart with respect to what the general infrastructure
should be (less time squabbling if I find somewhere to contribute ;-).
- Bruce
Reply to: