ello everyone, I would like to continue with the discussion about Python3 as a default and what it means for python packaging guidelines (f23+). This mail derives from [0][1]. Before I proceed to open a tickets I would like to hear your opinions first. *INTRO* (Not so) Recently the following change to the packaging guidelines was accepted[1]: "The unversioned macros, %{__python}, %{python_sitelib}, and %{python_sitearch} are generic macros that will always point to the default implementation. You may only use them with applications that need to choose to use the system's default version of python. (Currently this is the python2 interpreter.)" with the conjunction of another accepted and ongoing change targeted for f23 "Python 3 as default"[2] it means that %{__python} macro (and its derivatives) will/should change to point to python3 related paths. *USED TERMS* For further reference we need to *distinguish* between python *modules* and python *applications*. Simply said, application is not a module :). Application foo is not meant to be used within others python libraries via `import foo` and Both python3 and python2 versions of foo provides same functionality and therefore only one version is needed. This also includes scripts. DevAssistant is an *application* - We invoke DA and we don't care if it is python2 and python3 based, both will fulfill our task. pip is not a application, even though it is not used via import statement both python3 and python2 versions provides different functionality (python-pip installs python2 packages and python3-pip installs python3 packages), therefore it is a *module*. versioned macros - %{__python2}, %{__python3}, %{python3_sitearch} etc unversioned macros - %{__python}, %{python_sitelib}, %{python_sitearch} What needs to be done, assuming that {__python} will represent default python - python3. *MODULES* M1. First of all, all *modules* which aren't using versioned macros must be fixed to use them. This can be done right away as this is already part of packaging guidelines and all packages should comply with guidelines. * Note: There is around of 1000 packages using unversioned macros [3] M2. We should add provides for python2-foo modules. So python-foo would provide python2-foo. Fix all the modules to (Build)Require python2-bar instead of python-bar (python should also provide python2). Also if module foo ships bin file `baz` it should have `baz` and `baz2` bin file inside `python-foo` and `baz3` file inside `python3-foo`. This comply with upstream recommendation to keep /usr/bin/python point to python2, when (and if ever) upstream starts to recommend that /usr/bin/python should point to python3 we will follow. M3. All modules should be build with option --executable='/usr/bin/python(2,3)'. This could be resolved in [4] *APPLICATIONS* A1. All application must use the default python (of course only if upstream supports it). Applications can continue using {__python} macros and it derivatives. We should add a macro for (Build)Requires: %global py_default_major 3 # this could be part of f23 buildroot macros BuildRequires: python%{?py_default_major}-foo This way would maintainer have same specfile for both fedora and epel and also if the default python will change in the future the only thing that would need a change is the `py_default_major` value or we could make the value to be resolved by %{__python} macro. A2. Same as M3 (=should be resolved by [4]). *{__python} VS /usr/bin/python CONFUSION* Why is value of {__python} being changed and /usr/bin/python (along with python-foo being python2) is untached? I see this as two different situations or two different point of views. /usr/bin/python is a *user view*, as a user I would expect when I type python that it would fire up python2 interpreter as this is the default behaviour for all(-ArchLinux) distros and also python.org recommendation. Similarly when I type `sudo dnf install python-foo` I would expect to receive python2 version of foo package. This is why we stay with /usr/bin/python pointing to python2 and python-foo to provide python2 version of package. As a user I don't care for macros and their values, they are hidden from me => I am not confused, I get what I expect. {__python} is a *packager view*, as a packager, I follow the guidelines and I follow the changes. I understand that there are two major versions of interpreter and we are switching to the python3 to be the default one. For me, python-foo is just a name of the package. I operate with python(2/3)-foo as build(requires) and versioned macros within my specfile if the package is the module. I understand why python-foo provides python2 version of package, yet I operate only with versioned packages/macros => I am not confused, its just *python2* or *python3* for me. If my package is an application, I use only default python macros because I ship only one version of an application for one version of an interpreter => I am not confused its just *python* for me and *python* is the default distro python. *FUTURE* These suggestions (M1-M3, A1-A2) I've listed here are minimal changes needed for the Python3 as a default change. There is of course much more to deal with but for f23 timeframe it should be enough as it doesn't seem that /usr/bin/python will point to python3 any time soon [citation needed]. If those changes get accepted I would like to start applying them right away (for F23+ branches) because they should work even with __python macro still pointing to /usr/bin/python(2): 1. Fix all the modules specfiles and rebuild them because of new provides python2-foo. 2. Fix all the applications specfiles. (Rebuild is not needed.) 3. Change the default macro to point to /usr/bin/python3 (when anaconda is py3 ready) 4. Rebuild applications 5. Fix those which fails to build 6. Profit -- Robert Kuska {rkuska} [0] https://etherpad.mozilla.org/ep/pad/view/2Uqk0ikCll/vFEmg9YT2h [1] https://fedorahosted.org/fpc/ticket/498 [2] https://fedoraproject.org/wiki/Changes/Python_3_as_Default [3] https://pastebin.mozilla.org/8829944 (silly script used may miss some may contain redudant) [4] https://fedorahosted.org/fpc/ticket/513 -- Robert Kuska {rkuska}