Re: question on packaging of python applications
Moshe Zadka <moshez@math.huji.ac.il> writes:
> On 15 Nov 2000, Rob Tillotson wrote:
> > Moshe Zadka <moshez@math.huji.ac.il> writes:
> > > This isn't true. Python 1.5.2-compiled extensions will work just fine
> > > with Python 2.0.
> >
> > Hmm, they have changed the C API version several times in the past
> > with minor releases, I guess it just didn't occur to me that there
> > would be a major release without changes to it as well.
>
> The API changed, but AFAIK remained backwards-compatible.
How about the other way around? If the goal is to have 1.5.2 coexist
with 2.0 on the same machine, this still presents a potential problem
which will force packages to be dependent on one version or the
other.
If the goal is not coexistence, but simply transition, it really
doesn't matter -- at some point everything will be moved to 2.0
anyway.
> > Then we have no choice, all Python packages will have to depend on a
> > specific version of Python and be installed under that version's
> > library, no matter how the .pycs are supplied.
>
> Ugh! I was afraid you were going to say that.
Another alternative, perhaps, would be to move to a system like the
emacsen use -- that system solves a similar problem, namely that of
alternative implementations of a particular kind of language
interpreter that can share source code, but not byte-compiled files.
Emacs add-ons are packaged as elisp source which is placed in a common
location, then the infrastructure in the emacsen-common package
compiles the source using each installed emacs.
A Python version of this could work almost exactly the same way.
Packages would contain only the .py files, and put them in some
neutral location like /usr/share/python/site-packages. At install
time, a bit of infrastructure would first make a tree of symlinks
inside /usr/lib/pythonX.X/site-packages pointing to the source files,
then would compile them into .pyc and .pyo.
Of course, this is a solution for long-term coexistence, not for just
a transition from one major version to the next. It's probably
overkill for the current situation...
--Rob
--
Rob Tillotson N9MTB <robt@debian.org>
Reply to: