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