Bug 1737930 - trac depends on Python 2
Summary: trac depends on Python 2
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: trac
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1909452
Blocks: 1738907 1739023 1739024 1739025 1739027 1739028 1739032 1739033 1739034 1739039 1739042 1739045 F31_PY2REMOVAL 1739026 1739030 1739038 1739044 1739048 1754955
TreeView+ depends on / blocked
 
Reported: 2019-08-06 11:40 UTC by Lumír Balhar
Modified: 2020-12-21 14:59 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-21 14:59:56 UTC
Type: Bug


Attachments (Terms of Use)

Description Lumír Balhar 2019-08-06 11:40:26 UTC
Python 2.7 will reach end-of-life in January 2020, over 9 years after it was released. This falls within the Fedora 31 lifetime.
Packages that depend on Python 2 are being switched to Python 3 or removed from Fedora: https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal#Information_on_Remaining_Packages
Python 2 will be retired in Fedora 32: https://fedoraproject.org/wiki/Changes/RetirePython2

To help planning, we'd like to know the plans for trac's future. Specifically:


- What is the reason for the Python2 dependency? (Is it software written in Python, or does it just provide Python bindings, or use Python in the build system or test runner?) 

- What are the upstream/community plans/timelines regarding Python 3?

- What is the guidance for porting to Python 3? (Assuming that there is someone who generally knows how to port to Python 3, but doesn't know anything about the particular package, what are the next steps to take?)


This bug is filed semi-automatically, and might not have all the context specific to trac.
If you need anything from us, or something is unclear, please mention it here.

Thank you.

Comment 1 Gwyn Ciesla 2019-08-06 14:18:05 UTC
Upstream porting in progress. . .

https://trac.edgewall.org/timeline

Comment 2 Felix Schwarz 2019-08-06 15:05:37 UTC
According to upstream Python 3 will be tackled after the Trac 1.4 release (https://trac.edgewall.org/ticket/12130#comment:59). I don't have any insights if there is any timeline to release version 1.4 (https://trac.edgewall.org/milestone/1.4) but I'm sceptical if 1.6 will be stable before the Fedora 32 release.

Comment 3 Ben Cotton 2019-08-13 17:03:18 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 4 Ben Cotton 2019-08-13 17:03:24 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Comment 5 Lumír Balhar 2019-08-15 07:32:17 UTC
The current plan is to remove packages with dependency on Python 2 from Fedora 32 in the middle of November 2019. If you want to keep your package in Fedora after that date and you cannot port it to Python 3 yet, you need to request a FESCo exception for the package and all its Python 2 dependencies (even transitive) [1]. If you don't want to maintain it anymore, please orphan the package.

If you're considering filing the exception request, let us know. We can help (for example, we can help find all the dependencies).

[1] https://fedoraproject.org/wiki/Changes/RetirePython2#FESCo_exceptions

Comment 6 Felix Schwarz 2019-08-28 11:27:38 UTC
RjOllos @ trac-dev:
> Unfortunately we may not have a Python 3 compatible version ready by January 1st 2020,
https://groups.google.com/d/msg/trac-dev/eAUDDQ_NpBM/fHQzhYk_BAAJ

I'd be surprised if Trac manages to release 1.6 by F32 beta freeze.

Comment 7 Gwyn Ciesla 2019-08-28 14:31:04 UTC
I'll keep an eye on commits and see if there's a workable snapshot.

Comment 8 Miro Hrončok 2019-09-24 12:43:40 UTC
Assuming there will be nothing usable, should we expect an exception request for trac or is the plan to drop trac?

I'm asking because if it is the second case, we can start dropping Python 2 dependencies of several trac plugins.

Comment 9 Gwyn Ciesla 2019-09-24 13:12:27 UTC
I think an exception request is appropriate.

Comment 10 Petr Viktorin 2019-10-01 11:23:02 UTC
For trac and all but 5 of its plugins, you'll need to request an exception for:
- trac
- python2-setuptools
- python-genshi
- trac-* plugins, see list below
- possibly email2trac, if you care about it


Details and other plugins:

Trac itself depends on:
- python2-setuptools (you'll be asked to co-maintain: https://bugzilla.redhat.com/show_bug.cgi?id=1747850)
- python-genshi (check with the maintainer on python2-genshi plans)

There are also build-only dependencies that look like they're only used for testing. They should probably be skipped: pytest has many transitive dependencies tests won't run without it.
  - python2-pytest
  - python-docutils
  - python-lxml
  - python-pygments
  - python-configobj

Most plugins depend only on trac and its dependencies:
  - trac-CGit-plugin
  - trac-batchmodify-plugin
  - trac-blackmagictickettweaks-plugin
  - trac-customfieldadmin-plugin
  - trac-doxygen-plugin
  - trac-git-plugin
  - trac-iniadmin-plugin
  - trac-mastertickets-plugin
  - trac-monotone-plugin
  - trac-navadd-plugin
  - trac-privateticketsplugin
  - trac-sensitivetickets-plugin
  - trac-themeengine-plugin
  - trac-tocmacro-plugin
  - trac-tracnav-plugin
  - trac-vatar-plugin
  - trac-watchlist-plugin
  - trac-workflowadmin-plugin
  - trac-xmlrpc-plugin
  - email2trac

Dependency trees for other plugins (with trac and its dependencies omitted):

- trac-accountmanager-plugin:
  - babel (check with the maintainer on python2-babel plans)
    - pytz (you're the maintainer)
      - python2-pytest (for tests only; see above)

- trac-spamfilter-plugin:
  - babel (see above)
  - python-dns (check with the maintainer on python2-dns plans)
    - python-crypto (check with the maintainer on python2-crypto plans)
    - python2-typing (build only)
  - python-httplib2 (check with the maintainer on python2-httplib2 plans)
  - python-oauth2 (check with the maintainer on python2-oauth2 plans)
  - python-pillow (check with the maintainer on python2-pillow plans)
    - python-olefile (check with the maintainer on python2-olefile plans)
    - python-cffi (buld only)
    - python2-numpy (buld only)

- trac-authopenid-plugin
  - python-openid (orphaned)

- trac-bazaar-plugin
  - bzr (many dependencies incl. python-paramiko, python-pynacl)

- trac-mercurial-plugin
  - mercurial (see https://bugzilla.redhat.com/show_bug.cgi?id=1737931)

Comment 11 Felix Schwarz 2019-10-01 11:49:10 UTC
I maintain python-genshi and babel. If you plan to keep a Python 2 Trac I can keep these two packages alive in F32. (Please note that we dropped all tests for babel as python 2 dependencies like pytest are planned to be retired.)

(I'd prefer if you could coordinate the releng exception process also for genshi+babel. If necessary I can file a request myself but I prefer to do so only if it is clear that Trac is kept in F32.)

Comment 12 Miro Hrončok 2019-10-01 12:37:39 UTC
Does trac-bazaar-plugin use bzr trough Python interface or it just uses /usr/bin/bzr? see https://bugzilla.redhat.com/show_bug.cgi?id=1737937

Comment 13 Gwyn Ciesla 2019-10-01 13:38:15 UTC
I've updated Trac to 1.4, and dropped the test requirements. I also added python2-jinja2 since it was necessary.

Comment 14 Miro Hrončok 2019-10-01 14:34:39 UTC
> I also added python2-jinja2 since it was necessary.

Blocking bz1754955 then.

Comment 15 Miro Hrončok 2019-10-16 15:35:52 UTC
Can we get rid of trac-spamfilter-plugin? It has way too many deps.

Comment 16 Gwyn Ciesla 2019-10-16 15:45:51 UTC
paul@city-fan.org, is that ok with you?

Comment 17 Paul Howarth 2019-10-16 17:50:16 UTC
(In reply to Miro Hrončok from comment #15)
> Can we get rid of trac-spamfilter-plugin? It has way too many deps.

I'm reluctant to drop this as I'm actively using it myself. It may be possible to trim the deps though. Which ones look particularly onerous?

Comment 18 Miro Hrončok 2019-10-17 08:00:38 UTC
Most importantly:

- python2-typing is orphan
- maintainers of python-crypto want people to migrate to something else - see https://pagure.io/fesco/issue/2247

Comment 19 Miro Hrončok 2019-10-17 08:01:40 UTC
Oh, "maintainers of python-crypto" is actually you, sorry for not recognizing that :D

Comment 20 Petr Viktorin 2019-10-17 14:00:59 UTC
Check with maintainers of the dependencies about how onerous they are. Some maintainers might be getting ready to drop the Python 2 version at the announced date, mid-November.


FWIW, as jinja2 was added, the list for trac grew a bit:
- python-jinja2
  - babel (see above)
  - python-markupsafe

Comment 21 Paul Howarth 2019-10-21 19:12:58 UTC
(In reply to Miro Hrončok from comment #18)
> Most importantly:
> 
> - python2-typing is orphan

I just updated trac-spamfilter-plugin and there's no sign of python2-typing being pulled in. Where does it fit in the dependency tree?

https://kojipkgs.fedoraproject.org//packages/trac-spamfilter-plugin/1.4.0/0.1.20190829svn17127.fc32/data/logs/noarch/root.log

Comment 22 Miro Hrončok 2019-10-21 22:26:42 UTC
trac-spamfilter-plugin BuildRequires and Requires python2-dns. python-dns (source of python2-dns) BuildRequires python2-typing.

Comment 23 Paul Howarth 2019-10-22 07:33:33 UTC
OK, I see that python2-typing has been orphaned for 5 weeks although it does have a co-maintainer. I'm content to take ownership of that to keep python2-dns and hence trac-spamfilter-plugin  alive.

Any objections to that?

Comment 24 Petr Viktorin 2019-10-22 08:12:50 UTC
Not at all. Make sure to remove the orphan owner.

That leaves:
  - babel (see above)
  - python-dns (check with the maintainer)
    - python-crypto (check with the maintainer)
    - python2-typing (take ownership)
  - python-httplib2 (check with the maintainer)
  - python-oauth2 (check with the maintainer)
  - python-pillow (check with the maintainer)
    - python-olefile (check with the maintainer)
    - python-cffi (buld only, maybe can be trimmed)
    - python2-numpy (buld only, maybe can be trimmed)
  - python2-setuptools (co-maintain)

Comment 25 Paul Howarth 2019-10-22 13:32:30 UTC
> That leaves:
...
>   - python-pillow (check with the maintainer)
>     - python-olefile (check with the maintainer)
>     - python-cffi (buld only, maybe can be trimmed)
>     - python2-numpy (buld only, maybe can be trimmed)

The maintainer of python-pillow and python-olefile is fine with keeping them around as long as they are needed (see Bug #1764104).
The python-cffi build dependency has already been dropped.

Gwyn, you are the maintainer of python2-numpy: would you be OK with keeping this around along with trac?

Comment 26 Gwyn Ciesla 2019-10-22 13:54:16 UTC
I would; a lot else still needs it.

Comment 27 Miro Hrončok 2019-10-22 14:05:28 UTC
> a lot else still needs it.

Keeping it around for trac-spamfilter-plugin might be a good reason, but keeping it around for undefined "a lot" IMHO is not. Nothing with exception needs this. Most of the stuff that needs this is on it's way out.

Comment 28 Petr Viktorin 2019-10-22 14:20:52 UTC
If the numpy BR is kept, it brings in additional build dependencies:

- python-nose
- python2-pytest (with yet more deps, see above)

Comment 29 Felix Schwarz 2019-10-29 17:06:21 UTC
@Gwyn: Would you mind filing a releng exception for Trac + dependencies? I guess it is best to do this in one ticket.
(Obviously I care mostly about genshi+babel which I maintain.)

Comment 30 Gwyn Ciesla 2019-10-29 18:34:16 UTC
https://pagure.io/fesco/issue/2260

Comment 31 Paul Howarth 2019-11-05 20:21:05 UTC
(In reply to Petr Viktorin from comment #24)
> That leaves:
>   - babel (see above)
>   - python-dns (check with the maintainer)
>     - python-crypto (check with the maintainer)

I just submitted https://src.fedoraproject.org/rpms/python-dns/pull-request/1 to get python-dns to switch from python-crypto to python-pycryptodomex

There's an existing request for python-pycryptodomex for the volatility framework though that is being migrated to Python 3 soon. I'd be OK with taking python2-pycryptodomex if the current maintainer doesn't want to: I'm the python-crypto maintainer and I'd like to drop it in favor of python-pycryptodomex, and I've also done an EL-6 (!) branch of that recently.

>   - python-httplib2 (check with the maintainer)

Maintainer is OK (Bug #1764099)

>   - python-oauth2 (check with the maintainer)

No response from spot yet (Bug #1764101)

>   - python-pillow (check with the maintainer)
>     - python-olefile (check with the maintainer)
>     - python-cffi (buld only, maybe can be trimmed)
>     - python2-numpy (buld only, maybe can be trimmed)
>   - python2-setuptools (co-maintain)

These all seem OK from previous comments.

What should I do if the maintainer doesn't respond?

Comment 32 Miro Hrončok 2019-11-05 21:47:08 UTC
> What should I do if the maintainer doesn't respond?

IMHO You have 2 options:

a) https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

b) prepare python2-foo separate package, get it pre-reviewed and include it in the exception request



See also https://pagure.io/fesco/issue/2253 - python-httplib2 got recently orphaned

Comment 33 Paul Howarth 2019-11-07 14:52:41 UTC
(In reply to Paul Howarth from comment #31)
> (In reply to Petr Viktorin from comment #24)
> > That leaves:
> >   - babel (see above)
> >   - python-dns (check with the maintainer)
> >     - python-crypto (check with the maintainer)
> 
> I just submitted
> https://src.fedoraproject.org/rpms/python-dns/pull-request/1 to get
> python-dns to switch from python-crypto to python-pycryptodomex
> 
> There's an existing request for python-pycryptodomex for the volatility
> framework though that is being migrated to Python 3 soon. I'd be OK with
> taking python2-pycryptodomex if the current maintainer doesn't want to: I'm
> the python-crypto maintainer and I'd like to drop it in favor of
> python-pycryptodomex, and I've also done an EL-6 (!) branch of that recently.
> 
> >   - python-httplib2 (check with the maintainer)
> 
> Maintainer is OK (Bug #1764099)
> 
> >   - python-oauth2 (check with the maintainer)
> 
> No response from spot yet (Bug #1764101)

Spot has now replied that he's OK.

> >   - python-pillow (check with the maintainer)
> >     - python-olefile (check with the maintainer)
> >     - python-cffi (buld only, maybe can be trimmed)
> >     - python2-numpy (buld only, maybe can be trimmed)
> >   - python2-setuptools (co-maintain)
> 
> These all seem OK from previous comments.

Regarding the build dependencies of python2-numpy (Comment #28): Gwyn (Comment #26) says she's happy to maintain it so should I chase down those or will you do it Gwyn?

When all is done, should I tag the exception request for trac-spamfilter-plugin on to the existing trac one, or should I raise a new one?

Comment 34 Gwyn Ciesla 2019-11-07 14:55:33 UTC
(In reply to Paul Howarth from comment #33)
> (In reply to Paul Howarth from comment #31)
> > (In reply to Petr Viktorin from comment #24)
> > > That leaves:
> > >   - babel (see above)
> > >   - python-dns (check with the maintainer)
> > >     - python-crypto (check with the maintainer)
> > 
> > I just submitted
> > https://src.fedoraproject.org/rpms/python-dns/pull-request/1 to get
> > python-dns to switch from python-crypto to python-pycryptodomex
> > 
> > There's an existing request for python-pycryptodomex for the volatility
> > framework though that is being migrated to Python 3 soon. I'd be OK with
> > taking python2-pycryptodomex if the current maintainer doesn't want to: I'm
> > the python-crypto maintainer and I'd like to drop it in favor of
> > python-pycryptodomex, and I've also done an EL-6 (!) branch of that recently.
> > 
> > >   - python-httplib2 (check with the maintainer)
> > 
> > Maintainer is OK (Bug #1764099)
> > 
> > >   - python-oauth2 (check with the maintainer)
> > 
> > No response from spot yet (Bug #1764101)
> 
> Spot has now replied that he's OK.
> 
> > >   - python-pillow (check with the maintainer)
> > >     - python-olefile (check with the maintainer)
> > >     - python-cffi (buld only, maybe can be trimmed)
> > >     - python2-numpy (buld only, maybe can be trimmed)
> > >   - python2-setuptools (co-maintain)
> > 
> > These all seem OK from previous comments.
> 
> Regarding the build dependencies of python2-numpy (Comment #28): Gwyn
> (Comment #26) says she's happy to maintain it so should I chase down those
> or will you do it Gwyn?

Be my guest. :)

> When all is done, should I tag the exception request for
> trac-spamfilter-plugin on to the existing trac one, or should I raise a new
> one?

Comment 35 Miro Hrončok 2019-11-07 15:17:11 UTC
NumPy build deps python-nose and python2-pytest are "mine" and I want to dump that stack. The dependency is non-essential.


Do I read it correctly, that we have a full list now?


> When all is done, should I tag the exception request for
> trac-spamfilter-plugin on to the existing trac one, or should I raise a new
> one?


That one is now almost approved and tossing another group of packages in now would needlessly complicate stuff. Please open a separate one.

Comment 36 Paul Howarth 2019-11-07 15:23:42 UTC
(In reply to Gwyn Ciesla from comment #34)
> (In reply to Paul Howarth from comment #33)
> > Regarding the build dependencies of python2-numpy (Comment #28): Gwyn
> > (Comment #26) says she's happy to maintain it so should I chase down those
> > or will you do it Gwyn?
> 
> Be my guest. :)

How about dropping the BR's on python2-nose and python2-pytest and then just skipping the tests (which are already skipped for s390x and ppc64le)? It builds OK like this, I just tried it. What do you think?

Comment 37 Paul Howarth 2019-11-07 15:36:45 UTC
(In reply to Miro Hrončok from comment #35)
> NumPy build deps python-nose and python2-pytest are "mine" and I want to
> dump that stack. The dependency is non-essential.
> 
> 
> Do I read it correctly, that we have a full list now?

Not entirely. No response yet on python2-dns (Bug #1764096) and I've just re-opened Bug #1761070 for python2-pycryptodomex in the hope that python-dns will move from python-crypto to python-pycryptodomex (https://src.fedoraproject.org/rpms/python-dns/pull-request/1).

In the event of no response on python2-dns, I'd be happy to maintain that one myself, and I'd use python2-pycryptodomex as the backend, which I'm also prepared to maintain. The only circumstance in which python-crypto needs to be kept is if the python2-dns maintainer is happy to keep going with it but doesn't want to switch to python2-pycryptodomex.

Comment 38 Petr Viktorin 2019-11-07 15:48:09 UTC
I'd say that's enough info for an exception request. It's OK if python-crypto gets an exception but doesn't use it. And it's clear that python2-dns will have a maintainer, either you or Paul W.

Comment 39 Gwyn Ciesla 2019-11-07 15:57:37 UTC
(In reply to Paul Howarth from comment #36)
> (In reply to Gwyn Ciesla from comment #34)
> > (In reply to Paul Howarth from comment #33)
> > > Regarding the build dependencies of python2-numpy (Comment #28): Gwyn
> > > (Comment #26) says she's happy to maintain it so should I chase down those
> > > or will you do it Gwyn?
> > 
> > Be my guest. :)
> 
> How about dropping the BR's on python2-nose and python2-pytest and then just
> skipping the tests (which are already skipped for s390x and ppc64le)? It
> builds OK like this, I just tried it. What do you think?

Sounds good. Done.

Comment 40 Paul Howarth 2019-11-07 16:20:32 UTC
(In reply to Petr Viktorin from comment #38)
> I'd say that's enough info for an exception request. It's OK if
> python-crypto gets an exception but doesn't use it. And it's clear that
> python2-dns will have a maintainer, either you or Paul W.

https://pagure.io/fesco/issue/2266

Comment 41 Ben Cotton 2020-02-11 15:44:04 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Comment 42 Gwyn Ciesla 2020-05-01 14:06:43 UTC
Status update: F32 removed the python2 mod_wsgi pacakge, making Trac somewhat less useful and seems to be in no particular hurry to move to Python 3 upstream.

Comment 43 Paul Howarth 2020-05-01 15:16:37 UTC
(In reply to Gwyn Ciesla from comment #42)
> Status update: F32 removed the python2 mod_wsgi pacakge, making Trac
> somewhat less useful and seems to be in no particular hurry to move to
> Python 3 upstream.

Yes, I noticed that too, plus a bunch of other things I'd like to use with trac and/or moin.
I can't really support them in Fedora but I built some things for my own use until the migration to Python 3 happens:
http://www.city-fan.org/ftp/contrib/python2-support/

Note: I haven't tried any of those yet as I haven't updated to F-32 yet.

Comment 44 Paul Howarth 2020-05-06 07:58:09 UTC
(In reply to Felix Schwarz from comment #11)
> I maintain python-genshi and babel. If you plan to keep a Python 2 Trac I
> can keep these two packages alive in F32. (Please note that we dropped all
> tests for babel as python 2 dependencies like pytest are planned to be
> retired.)
> 
> (I'd prefer if you could coordinate the releng exception process also for
> genshi+babel. If necessary I can file a request myself but I prefer to do so
> only if it is clear that Trac is kept in F32.)

Hi Felix, currently trac is still around and on Python 2 for F-33 but babel dropped Python 2 support from F-33 onwards (via a conditional in the spec rather than completely stripping it out). As a result, trac-accountmanager-plugin is FTI on F-33 (#1832058). Would you consider extending Python 2 support for babel until such time as trac completes its migration to Python 3?

Comment 45 Felix Schwarz 2020-05-06 09:31:37 UTC
If trac can stay on Fedora 33 and we still have pytz/setuptools I don't see a problem supporting python2-babel.

Gwyn: Do you see any progress in Trac's Python 3 migration?

Comment 46 Gwyn Ciesla 2020-05-06 13:24:24 UTC
Not recently.

Comment 47 Gwyn Ciesla 2020-05-07 14:31:02 UTC
Nils, can you please reinstate python2-babel? We need it for python2-jinja2 and trac.

Comment 48 Felix Schwarz 2020-05-08 14:05:34 UTC
I can do that later (unless Philipp is faster).

Comment 49 Felix Schwarz 2020-05-08 20:49:10 UTC
I added python2-babel to F33+ again.

Comment 50 Felix Schwarz 2020-05-21 20:05:33 UTC
Current target release for Python 3 support in Trac is version 1.5.2 (to be released on July 4 - https://groups.google.com/d/msg/trac-dev/qPf4k35rZ9I/qbUzkMSfAQAJ )

Comment 51 Lumír Balhar 2020-07-20 04:51:19 UTC
Do we have an update here? python-dns has been released upstream and it is ready to be updated to 2.0.0 without Python 2 support.

Comment 52 Gwyn Ciesla 2020-07-20 13:59:31 UTC
Last estimate I heard was this year-ish.

Comment 53 Lumír Balhar 2020-07-23 08:04:37 UTC
Because we want to update python-dns to the latest version before Fedora beta release, I've decided to prepare a split package python2-dns so the update won't be blocked. Who wants to co-maintain python2-dns?

Comment 54 Paul Howarth 2020-07-23 10:34:37 UTC
I'll help (since I need it for trac-spamfilter-plugin). FAS: pghmcfc


Note You need to log in before you can comment on or make changes to this bug.