[EPEL-devel] Python 3 discussion

[Bohuslav Kabrda]

----- 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 at redhat.com>
> Software Engineer, Hosted & Shared Services
> Red Hat, Inc.

Thanks a lot,
Slavek