(I've miss hitted enter and sent the email earlier)
----- Original Message -----
From: "Robert Kuska" <rkuska(a)redhat.com>
To: "Fedora Python SIG" <python-devel(a)lists.fedoraproject.org>
Sent: Monday, April 20, 2015 10:05:44 AM
Subject: Re: Python3 as default
----- Original Message -----
> From: "Toshio Kuratomi" <a.badger(a)gmail.com>
> To: "Fedora Python SIG" <python-devel(a)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(a)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(a)lists.fedoraproject.org
> >
https://admin.fedoraproject.org/mailman/listinfo/python-devel
>
> _______________________________________________
> python-devel mailing list
> python-devel(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/python-devel
_______________________________________________
python-devel mailing list
python-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel