----- Original Message -----
<snip>
> > * applications will need to be rebuilt to pick up a change
from
> > python34-* to python35-*
> > which is a bit unfortunate.
> >
> > Is there any reason why we shouldn't just upgrade applications to the
> > python35-* stack straight away, by providing python3-*?
>
> Yeah. First of all, it may happen that there are some minor backwards
> incompatibilities. Lots of packages run tests during buildtime, so
> these will be caught.
> Another reason is that there are applications, which store files in
> /usr/lib/python3.X/site-packages - these need to be rebuilt anyway,
> since they have the Python minor version incorporated in path of
> files.
> I really think that we should rebuild applications with new Python
> 3.X.
Well, they should really be using pkg_resources instead of hardcoding
the path... but yes I take your point. Rebuilding for the newer Python
stack makes sense.
There is no hardcoded path. The problem is that /usr/bin/python3.4 import modules from
/usr/lib[64]/python3.4/site-packages. So when /usr/bin/python3 switches all of a sudden
from python3.4 to python3.5, the app will try to import the module from
/usr/lib[64]/python3.5, but it's not there. That's why I think we should use
/usr/bin/python3.X rather than /usr/bin/python3.
We will need to make sure that setuptools-generated entry points
have
a shebang of /usr/bin/python3.4 rather than just /usr/bin/python3
though, so that the scripts are always invoked with the same Python
stack they are built for. Currently on Fedora they have
/usr/bin/python3. This might need a patch to
setuptools/distutils/whatever it is?
Good point. I *think* setuptools uses the executable with which it was executed for
hashbangs, so if you use "/usr/bin/python3.4 setup.py build", hashbangs will
have "#!/usr/bin/python3.4". I have already modified the __python3 macro in my
copr to point to /usr/bin/python3.4 instead of /usr/bin/python3, but I haven't rebuilt
the other packages with it yet. I'm putting it on my TODO list to check this.
--
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Hosted & Shared Services
Red Hat, Inc.
Thanks a lot,
Slavek