Python3 as default

Mon Apr 20 08:17:33 UTC 2015

(I've miss hitted enter and sent the email earlier)

----- Original Message -----
> From: "Robert Kuska" <rkuska at redhat.com>
> To: "Fedora Python SIG" <python-devel at lists.fedoraproject.org>
> Sent: Monday, April 20, 2015 10:05:44 AM
> Subject: Re: Python3 as default
> 
> 
> 
> ----- 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.
> 

https://fedorahosted.org/fpc/ticket/281#comment:19

> 
> > 
> > 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.
> > 

Yes, I want to start right away after the guidelines get accepted.

> > (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.

That's a reason why I want to allow packagers to use unversioned macros
within applications specfiles and introduce the %{py_default_major} macro so they
can keep one specfile for both epel and fedora.

BuildRequires: python%{?py_default_major}-foo
->
EPEL: python-foo
Fedora: python3-foo

%install
%{__python} setup.py install
->
EPEL: /usr/bin/python setup.py install
Fedora: /usr/bin/python3 setup.py install

and same for %{python_site*} macros.

Also thats the reason why I proposed to create also unversioned macros.
https://fedorahosted.org/fpc/ticket/513#comment:15

Of course if someone wish to, they can have different specfiles. It is not 'must
to have' just 'nice to have'.

> > 
> > 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
> _______________________________________________
> python-devel mailing list
> python-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/python-devel