Python3 as default

Mon Apr 20 08:05:44 UTC 2015

----- Original Message -----
> From: "Toshio Kuratomi" <a.badger at gmail.com>
> To: "Fedora Python SIG" <python-devel at lists.fedoraproject.org>
> Sent: Friday, April 17, 2015 2:14:20 PM
> Subject: Re: Python3 as default
> 
> 
> 
> 
> On Apr 15, 2015 2:57 AM, "Robert Kuska" < rkuska at redhat.com > wrote:
> 
> 
> > 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*.
> > 
> This should probably be phrased differently in the final draft. Pip is an
> application. But because we need it to provide both a python 2 and python 3
> cli tool it follows the same guidelines as dual-python-version modules
> rather than applications. This category might even deserve its own
> subsection as there's a couple other specific things to do with these types
> of packages.
> 

Yes, I agree that this needs better wording for the guidelines draft.

> 
> > 
> > *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.
> 
> I'd make the following its own should bullet as the first part of M2 is more
> important. the python-foo package names aren't going away so if we get into
> a time crunch for f22, this second portion isn't as critical as the first.
> 

That's a good point as it will save us from the figuring out the
rebuild dependency chain.

> > 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`.
> 
> I disagree with this but I think it's probably just an omission of some
> information. We need to make clear here that this is only for bin files
> where it is necessary to shop a version that runs on py2 and a version that
> runs on py3. Most packages should just ship one version of the bin scripts
> for the default python version. (Note, I don't think we can wrap this choice
> into a convenient macro. It'll probably need a spec file conditional if
> packagers want to have a single spec for multiple branches.)
> 

That's meant to be only for the applications like a modules/modules like a applications
(pip, pytest and similiar).

I agree that that /usr/bin/foo is enough for an (pure) application module. No
need for a versioned one.

> 
> > 
> > M3. All modules should be build with option
> > --executable='/usr/bin/python(2,3)'. This could be
> > resolved in [4]
> > 
> 
> I'm not sure if this is true. Pure modules don't have a shebang line so I
> think the choice of which python interpreter runs them and determines the
> path they install into is sufficient.

Again, this point was constructed with an assumption of pip and pytest being 
(kind of) modules and also with a possibility of creating macros for easier
packaging which contain `--executable` in the draft.

> 
> From a message from ncoghlan a long time ago I think things in bin should use
> /usr/bin/python(2,3) in their shebang as long as the setup.py is invoked
> with the versioned path. So --executable is extraneous for these purposes.
> (But if [4] is the -s guideline update, we would want to use --executable
> for that purpose for packages providing things in bin).
> 
> > *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
> > 
> 
> Couple thoughts here:
> 
> (1)
> We should have a package cleanup to implement these like we had for removing
> the python-setuptools-devel buildrequires and the python-pillow update.
> Since this could be a rather more invasive change to spec files we should
> start this sooner to allow package maintainers to update their spec files on
> their own but still allow us plenty of time to fix all the specs.
> 
> (2)
> Conditionalizing specs for multiple distributions has been something of an
> anti goal in the past as it obfuscated the spec file. We have a guideline
> not to do this for other distributions. Since our packagers work on both
> fedora and epel, it's reasonable to want to conditionalize so they can keep
> a single spec file if they desire. However,I think we should also allow
> people to keep simpler specs and simply maintain diverged spec files between
> python 3 by default and python 2 by default distro versions. So I think we
> should allow people to hardcore things like "buildrequires: python3-foo" and
> maintaining two specs if they wish.
> 
> If so, then the guideline draft would need to make clear which portion of
> this is the policy and goals and which is implementation.
> 
> We'd also want to mention whether people who participate in cleaning up the
> packages for other maintainers will use a specific style or can use either
> method just so there's no surprises later. (I think the style being up to
> the person porting is fine as long as that expectation is properly set.)
> 
> -Toshio
> > --
> > 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}
> > _______________________________________________
> > python-devel mailing list
> > python-devel at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/python-devel
> 
> _______________________________________________
> python-devel mailing list
> python-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/python-devel