Re: [EPEL-devel] Python 3 discussion
- Original Message -
On Mar 02 06:53, Bohuslav Kabrda wrote:
- Original Message -
...SNIP...
I think applications should use /usr/bin/python3.4 (at least packaged
applications). Otherwise we could theoretically end up in a situation
where /usr/bin/python3 is owned by python35, but the application RPM still
has python34- dependencies and thus the app doesn't work.
I think this is actually one of the reasons why I thought it makes sense to
keep both python34 and python35 living together in the state where
python35 is the main python3 (having the default macros and owning
/usr/bin/python3) and python34 is the other. Let's take this example:
- there's an application foo written in python, which requires six
- it doesn't make sense to build the application for both python34 and
python35, since it's an application, not a library
- this means it doesn't make sense for package maintainer to introduce the
%python3_{other or next}* macros to the specfile, maintainer just wants to
build with the python3
- so this means that we should do this:
-- python 3.5 is released, we build it in EPEL and turn with_python3_other
to 1 in python3-pkgversion-macros
-- then there's a period when python34 and python35 coexist and python34 is
the main python - in this period, *libraries* are rebuilt to provide
both python34- and python35- subpackages
-- python34 and python35 are switched (the default macros now point to 35
and it also owns /usr/bin/python3 now)
-- then there's a period when python34 and python35 coexist and python35 is
the main python - in this period, *applications* are rebuilt for
python35 (may take some time, there will likely be a period when there are
some apps on python34 and some already on python35)
^ Is this step part of a coordinated mass-rebuild, or is this just a
period of time after we make the announcement: Hey Packagers: be sure
to rebuild for python35?
That's a good question. I guess we should standardize how this will be done.
Something like:
- there's an announcement on epel-devel that python35 is the main python3 and
packagers should rebuild their packagers (and users their apps/scripts/...)
- wait for a week (two?)
- open bugs for packages that haven't been rebuilt during the previous week and
get them fixed ASAP
One alternative might be to do python35 in a side tag, after which we
could release the libraries and applications, and deprecate python34
together. This might take quite a bit more work though.
+1, I don't want to introduce side tags to the process.
-- when all applications are rebuilt for 35, with_python3_other is set to 0
and we now have just python35 and it's the main python3
Does this make sense or am I missing something? I'd need to do some minor
changes+explanations to my proposal to accomodate this, but I still think
it makes sense.
What about all of the old python34 packages left on their systems after
retirement? Is there some way they can get cleaned up automatically?
I'm not sure about that... and I'm also not sure we want to do that, people
may still want to keep these around for their own non-system applications
to migrate.
Great discussion so far!
Brian
Thanks,
Slavek
--
Brian Stinson
bstin...@ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] Python 3 discussion
On Tue, 3 Mar 2015 07:46:00 -0500 (EST) Bohuslav Kabrda bkab...@redhat.com wrote: ^ Is this step part of a coordinated mass-rebuild, or is this just a period of time after we make the announcement: Hey Packagers: be sure to rebuild for python35? That's a good question. I guess we should standardize how this will be done. Something like: - there's an announcement on epel-devel that python35 is the main python3 and packagers should rebuild their packagers (and users their apps/scripts/...) - wait for a week (two?) - open bugs for packages that haven't been rebuilt during the previous week and get them fixed ASAP I'd say just doing the mass rebuild by a provenpackager or the like would be easier than filing bugs and waiting. Also, we need to coordinate the update with them in it... ideally they would all be in the same update? kevin pgpXNkwEu2jqS.pgp Description: OpenPGP digital signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] Python 3 discussion
On Tue, 3 Mar 2015 08:31:20 -0500 (EST) Bohuslav Kabrda bkab...@redhat.com wrote: Today, I've made some changes to the proposal to accomodate comments from the previous meeting and from discussion on this list. The diff is here: https://fedoraproject.org/w/index.php?title=User%3ABkabrda%2FEPEL7_Python3diff=405180oldid=404782 I'd appreciate comments, I hope I made it clearer and more explanatory. Overall I like it. I suspect we will run into things and need to fine tune it, but thats normal and good. ;) kevin pgpQg8wK6RaJI.pgp Description: OpenPGP digital signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] Python 3 discussion
On 03/03/2015 06:31 AM, Bohuslav Kabrda wrote: Today, I've made some changes to the proposal to accomodate comments from the previous meeting and from discussion on this list. The diff is here: https://fedoraproject.org/w/index.php?title=User%3ABkabrda%2FEPEL7_Python3diff=405180oldid=404782 I'd appreciate comments, I hope I made it clearer and more explanatory. Thanks for your comments, Slavek ___ Can we add the proper _sitelib / _sitearch macros to the example spec file? Thanks. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] Python 3 discussion
- 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 dcall...@redhat.com Software Engineer, Hosted Shared Services Red Hat, Inc. Thanks a lot, Slavek ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
