Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Formulas still using Python 2 #47050

Closed
60 of 62 tasks
fxcoudert opened this issue Nov 22, 2019 · 35 comments
Closed
60 of 62 tasks

Formulas still using Python 2 #47050

fxcoudert opened this issue Nov 22, 2019 · 35 comments
Assignees
Labels
outdated PR was locked due to age python Python use is a significant feature of the PR or issue

Comments

@fxcoudert
Copy link
Member

fxcoudert commented Nov 22, 2019

Python 2.7 is going away soon… and we still have 61 formulas using it (out of 389 Python formulas). We need to start thinking about migrating them, or dropping them.

Below the formulas are sorted by install count for 30 days, so we can prioritise our work. Some formulas were audited in the past (I added a does not support Python 3 comment), but not all. Some may have newer versions compatible with Python 3.

Top formulas

High usage

Lower usage

Stragglers

@fxcoudert fxcoudert added the python Python use is a significant feature of the PR or issue label Nov 22, 2019
@Bo98
Copy link
Member

Bo98 commented Nov 22, 2019

Pinging @chrmoritz since he knows a bit about the node@10 situation.

@Bo98
Copy link
Member

Bo98 commented Nov 22, 2019

On the topic of node@8, I can already say to remove that with Python 2. They share an EOL date.

@fxcoudert
Copy link
Member Author

Pinging @tschoonj for his knowledge on the GTK world, and apps like terminator and vte, which are among the most-used in this list

@tschoonj
Copy link
Contributor

I don't think terminator has properly worked since we migrated to the Gtk quartz backend many years ago, because vte doesn't seem to support it properly. So probably these two are ripe for deletion.

Deleting pygtk would make sense, seeing as it has been unmaintained for many years, and people are supposed to use gobject-introspection instead. I guess this would give rise to complaints though 😄

@Bo98
Copy link
Member

Bo98 commented Nov 22, 2019

py2cairo

We have py3cairo, so that will be an eventual delete.

py3cairo could also be renamed to pycairo.

@bayandin
Copy link
Member

osc and dnsviz switched to Python 3 in #47052

@bayandin
Copy link
Member

Uhh, I wish this done after Python 3.8

@bayandin
Copy link
Member

ipython@5 — the last version with python2 support, so it's ok to delete them together.

@fxcoudert
Copy link
Member Author

@bayandin there is no hurry, we can put it on hold

@chrmoritz
Copy link
Contributor

chrmoritz commented Nov 23, 2019

Regarding the nodesituation:

  • node and node@12 are compatible with Python 3 without patching (pending v13.2.0 in node 13.2.0 #47042)
  • node@8 isn't worth fixing because it will be EOL together with Python 2 at the end of the year
  • node@10 is more difficult, because it has high install count and will be supported until April 2021
    • I don't think we will get upstream Python 3 supported because the bundled V8 version it uses is too old for Python 3 support => we would need to patch it ourself
    • I was able to make configure Python 3 compatible my applying a couple of upstream patches (most of them apply cleanly, some required some trivial backporting): chrmoritz@0e5c670 (mostly the same patches that landed in v12.13.1 and some older ones)
    • Then I tried to make building with make Python 3 compatible, but unfortunately the outdated V8 version in node@10 hast a lot of scripts used during the build which are not Python 3 compatible (and we can't simply backport the whole V8 upgrade here obviously)
    • I tried to copy the newer Python 3 compatible scrips over, but unfortunately there were some interface changes making them not compatible with the rest of the older codebase / the gyp files, progress that far can be found
    • So we would need to just backport the Python 3 compatible fixes from V8 here, which is still quite a bit of work to do

@Bo98

This comment has been minimized.

@xu-cheng
Copy link
Member

xu-cheng commented Nov 23, 2019

FYI, the list is not completed. You are missing the following formulae:

$ rg 'uses_from_macos "python@2"'
Formula/ginac.rb
17:  uses_from_macos "python@2"

Formula/blockhash.rb
18:  uses_from_macos "python@2"

Formula/aws-elasticbeanstalk.rb
16:  uses_from_macos "python@2"

Formula/bazaar.rb
16:  uses_from_macos "python@2"

Formula/fail2ban.rb
15:  uses_from_macos "python@2"

Formula/autojump.rb
16:  uses_from_macos "python@2"

Though they have no effect on macOS, you would still need to address them somehow.

@EricFromCanada
Copy link
Member

EricFromCanada commented Nov 27, 2019

auditbeat/metricbeat: migration in progress at elastic/beats#14798
charm-tools: migrated in #47275

@issyl0
Copy link
Member

issyl0 commented Dec 4, 2019

The bazaar VCS (with its uses_from_macos python@2 in our formula) doesn't support Python 3. It hasn't had any updates from Canonical since version 2.7.0 (the current in Homebrew) which was released in 2016. There's a fork called breezy that works with Python 3.

@dawidd6
Copy link
Member

dawidd6 commented Dec 7, 2019

There is also asciidoc which uses system python2.

@alebcay
Copy link
Member

alebcay commented Dec 7, 2019

After discussion in #47511, looks like ipython@5 will be up for deletion at the end of the calendar year as upstream will be dropping support.

@iMichka
Copy link
Member

iMichka commented Dec 9, 2019

Please update the list from @fxcoudert whenever possible.
All the formulae marked with a ☠️ will be removed on 01.2020 in the same PR as python@2.

iMichka added a commit to iMichka/homebrew-core that referenced this issue Dec 10, 2019
9 downloads in the last 30 days
No commits since Feb. 2018. Project looks dead.
Does not support Python 2

See Homebrew#47050
@iMichka iMichka mentioned this issue Dec 10, 2019
5 tasks
iMichka added a commit to iMichka/homebrew-core that referenced this issue Dec 10, 2019
11 downloads in the last 30 days
No commits since Apr. 2017. Project looks dead.
Does not support Python 2

See Homebrew#47050
@iMichka iMichka mentioned this issue Dec 10, 2019
5 tasks
iMichka added a commit to iMichka/homebrew-core that referenced this issue Dec 10, 2019
11 downloads in the last 30 days
No commits since Apr 2014. Project looks dead.
Does not support Python 2

See Homebrew#47050
@EricFromCanada
Copy link
Member

terminator has a Python 3 milestone, but I'd be surprised if they got a release out before the end of the year.

@iMichka
Copy link
Member

iMichka commented Dec 11, 2019

I think that we have two options:

  1. Let the full pygtk diffuse gtk-mac-integration nicotine-plus pygtkglext pygtksourceview terminator vte zim stack depend on system Python 2. This leaves the door open for terminator to migrate (though it looks like this may take some time)
  2. Add this list of formulae to WIP: python@2: delete #47750 and delete everything with Python@2. pygtk is dead and unmaintained, so we will remove it one day or another anyway ...

iMichka added a commit that referenced this issue Dec 12, 2019
23 Downloads over the last 30 days
No new release since 2017, project looks dead
Does not build with Python 2

See #47050
iMichka added a commit that referenced this issue Dec 12, 2019
25 Downloads in the last 30 days
No new release since 2013, project looks dead
Does not build with Python 2

See #47050
iMichka added a commit that referenced this issue Dec 12, 2019
13 Downloads in the last 30 days
Looks like this will not be ported to Python 3
nicotine-plus/nicotine-plus#99

See #47050
@SMillerDev
Copy link
Member

I'd say it's easy enough to add a formula once it meets the standards again. 🚮 for me

@tschoonj
Copy link
Contributor

pygtk is only an optional dependency of gtk-mac-integration, so I would recommend to just drop pygtk from the list of dependencies.

I would vote to delete the pygtk formula. People should really not be using this anymore.

@MikeMcQuaid
Copy link
Member

2. Add this list of formulae to #47750 and delete everything with Python@2. pygtk is dead and unmaintained, so we will remove it one day or another anyway ...

This seems reasonable to me. It's going to be less painful for people to have these dropped in one than a few different times.

pygtk is only an optional dependency of gtk-mac-integration, so I would recommend to just drop pygtk from the list of dependencies.

👍

iMichka added a commit to iMichka/homebrew-core that referenced this issue Dec 12, 2019
30 Downloads in the last 30 days
No webpage with source code, no new release since 2017
Does not work with Python 3

See Homebrew#47050
@iMichka
Copy link
Member

iMichka commented Dec 12, 2019

I was not able to get gtk-mac-integration going with Python 3 and pygobject3. It always tries to fall back to system python 2. Does somebody want to have a look? I'll proceed with the other packages. Else, gtk-mac-integration may be deleted too during the Python@2 removal.

@tschoonj
Copy link
Contributor

@iMichka See #47799

iMichka added a commit that referenced this issue Dec 13, 2019
30 Downloads in the last 30 days
No webpage with source code, no new release since 2017
Does not work with Python 3

See #47050
@iMichka
Copy link
Member

iMichka commented Dec 13, 2019

Here is the srategy I have used for all the changes done until now:

  • Stuff that is completely unmaintained (no new releases in the last 2 years) and has a low donwload count: deleted right away.
  • Stuff that is maintained and has a low download count: I opened an issue upstream and will give them a few more days to update: if this does not work, we will migrate these to system Python 2 (uses_from_macos "python@2")
  • Stuff from the pygtk stack: pygtk diffuse pygtkglext pygtksourceview terminator vte zim and EOL stuff like node@8 are added to the python@2 deletion PR: WIP: python@2: delete #47750, and will be deleted all at once.
  • Remaining stuff with high download count is migrated to uses_from_macos "python@2", which gives these package some more months to live on mac (node@10 py2cairo numpy@1.16 opencv@2 offlineimap ...), but eventually these will be deleted too at one point

I must say that some packages are in a sort of grey area. I hope I did not do too many mistakes ... but all of these had 11 years to prepare. We need to draw a line somewhere.

@MikeMcQuaid
Copy link
Member

  • Stuff that is completely unmaintained (no new releases in the last 2 years) and has a low donwload count: deleted right away.

I would personally say this should only happen if it has a zero download count or is broken.

  • Remaining stuff with high download count is migrated to uses_from_macos "python@2", which gives these package some more months to live on mac (node@10 py2cairo numpy@1.16 opencv@2 offlineimap ...), but eventually these will be deleted too at one point

I would say these get deleted when macOS drops Python 2.

@iMichka
Copy link
Member

iMichka commented Dec 14, 2019

Stuff that is completely unmaintained (no new releases in the last 2 years) and has a low donwload count: deleted right away.

I would personally say this should only happen if it has a zero download count or is broken.

We do delete formulae on a regular basis which do not have a zero download count, and which are sometimes not broken. EOL formulae for example. And I often see things being deleted from homebrew-core, even if in principle we could put more effort to maintain these. It is hard to have a clear guideline here.

I do not believe I took too many risks deleting these formulae. They all had 11 years to be ready, and looked really dead to me. If anybody opens an issue because their favourite tool is gone, I'll add it back.

We do not have a proper deletion process, but this is maybe something we should discuss somewhere else, as this is not solely related to Python 2, and is more a general topic.

Remaining stuff with high download count is migrated to uses_from_macos "python@2", which gives these package some more months to live on mac (node@10 py2cairo numpy@1.16 opencv@2 offlineimap ...), but eventually these will be deleted too at one point

I would say these get deleted when macOS drops Python 2.

Agreed. Not sure when this will be, but I hope it will not take 10 more years. node@10 will be EOL mid-2020 anyway. The others may remain though because I do not know if they have a formal EOL deadline.

I don't know why you closed this issue? I would really like to finish off the list.

There should be only 2 things remaining here:

@iMichka iMichka reopened this Dec 14, 2019
@iMichka iMichka self-assigned this Dec 14, 2019
@chrmoritz
Copy link
Contributor

chrmoritz commented Dec 14, 2019

node@10 will be EOL in April 2021 (and not 2020), so we might get a problem here too, if Apple decides to drop Python 2 in macOS 10.16. However I've not completely given up patching in Python 3 compatibility yet.

Also whats the plan with the python symlink after python@2 gets removed? Should the python symlink (pointing to Python 3) stay hidden in libexec or should it be normally linked to HOMEBREW_PREFIX together with python3?

@jonchang
Copy link
Contributor

Also whats the plan with the python symlink after python@2 gets removed? Should the python symlink (pointing to Python 3) stay hidden in libexec or should it be normally linked to HOMEBREW_PREFIX together with python3?

Unfortunately PEP 394 does not seem provide much guidance on this, only that it should point to the same thing as either python2 or python3.

I think pointing python to python3 is only sensible once macOS no longer ships system Python 2, to avoid shadowing the system version.

@iMichka
Copy link
Member

iMichka commented Dec 15, 2019

Yes, we will strictly follow PEP 394. Last time we tried to do something else, there was a juge backslash from the community. So python will "never" point to python3. Unless upstream decides to review the PEP.

So if Python 2 is removed from macOS, you will have no python executable anymore. (unless Apple decides something else, who knows ...).

I personally disagree with the PEP, and think they should have given more details on what happens after 2020. But we will follow it as we have no other choice.

@fxcoudert
Copy link
Member Author

Closing the tracking issue. Thanks everyone!

@iMichka
Copy link
Member

iMichka commented Jan 6, 2020

offlineimap is still open #47834

@fxcoudert
Copy link
Member Author

Yeah, you can reopen if you feel like it, but it seems a bit overkill to have a tracking issue for one open PR :)

@iMichka
Copy link
Member

iMichka commented Jan 6, 2020

Forgot to say that I was OK to close this issue :)

@lock lock bot added the outdated PR was locked due to age label Feb 5, 2020
@lock lock bot locked as resolved and limited conversation to collaborators Feb 5, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated PR was locked due to age python Python use is a significant feature of the PR or issue
Projects
None yet
Development

No branches or pull requests