homepage

In past years, very few Python core developers took care of the Solaris support. The latest significant Solaris enhancement was in 2018 with the addition of a new Solaris st_fstype attribute to os.stat(), in Python 3.7, by Jesús Cea Avión (bpo-32659).
Another recent Solaris-related change is bpo-41687: "Fix implementation of sendfile to be compatible with Solaris".
On the Oracle side, there was an article about Python on Solaris in 2019:
"Future of Python on Solaris" by Darren Moffat 
https://blogs.oracle.com/solaris/future-of-python-on-solaris
I now that Giampaolo Rodola cares of the Solaris support for his psutil project:
https://github.com/giampaolo/psutil/
It's unclear to me if Oracle still plans to maintain Solaris. The latest release was published 2 years ago. The Wikipedia article says: "While Oracle did have a large layoff of Solaris development engineering staff, development continues today of which Solaris 11.4 was released in 2018."
https://en.wikipedia.org/wiki/Solaris_(operating_system)
There is currently 25 open issues which could be closed if we drop the Solaris support.
See also the PEP 11 for the process.
I asked asked 4 years ago (in 2016) if Solaris support should/can be removed:
"OpenIndiana and Solaris support"
https://mail.python.org/archives/list/python-dev@python.org/message/NOT2RORSNX72ZLUHK2UUGBD4GTPNKBUS/
Python has no longer buildbot workers running on Solaris or a Solaris variant (OpenIndiana, Illumos, etc.).
I propose to drop the Solaris support in Python to reduce the maintenance burden.
Python has a few features specific to Solaris:
* st_fstype attribute of os.stat()
* select.devpoll and selectors.DevpollSelector
* time.CLOCK_HIGHRES constant
* stat.S_ISDOOR()
* tarfile: "Solaris extended header" (no need to remove this one)
Solaris has many names and variants:
* SunOS
* SRV4
* Solaris
* Illumos (still active in July 2020 at least)
* OpenSolaris: "On Friday, August 13, 2010, details started to emerge relating to the discontinuation of the OpenSolaris project and the pending release of a new closed-source, proprietary version of Solaris, Solaris 11." says Wikipedia
* OpenIndiana (latest release in 2020)
I'm not sure on how to process? Deprecate all Solaris-specific features in Python 3.10, make sure that Python 3.11 cannot be built on Solaris anymore, and drop the code in Python 3.12? Or drop everything as soon as possible in Python 3.10?
The alternative is to leave the code unchanged and let the code slowly die, as we did for other platforms like HP-UX and IRIX.
See also my notes on platforms supported by Python:
https://pythondev.readthedocs.io/platforms.html
Attached draft PR gives an idea on how much code can be removed if Solaris support is removed. A coase estimation is the removal of 700 lines:
 Doc/c-api/init.rst | 3 +-
 Doc/distutils/apiref.rst | 1 -
 Doc/library/gettext.rst | 10 +-
 Doc/library/os.rst | 12 +-
 Doc/library/platform.rst | 5 +-
 Doc/library/posix.rst | 8 +-
 Doc/library/sys.rst | 3 +-
 Doc/library/sysconfig.rst | 1 -
 Doc/library/time.rst | 13 +-
 Doc/using/unix.rst | 7 -
 Include/pyport.h | 5 -
 Lib/cgi.py | 4 +-
 Lib/ctypes/test/test_byteswap.py | 2 +-
 Lib/ctypes/util.py | 100 ++--------
 Lib/distutils/command/bdist.py | 2 +-
 Lib/distutils/tests/support.py | 2 +-
 Lib/distutils/tests/test_build_ext.py | 21 --
 Lib/distutils/util.py | 11 --
 Lib/gettext.py | 3 -
 Lib/logging/handlers.py | 2 -
 Lib/platform.py | 27 +--
 Lib/sysconfig.py | 11 --
 Lib/test/fork_wait.py | 4 +-
 Lib/test/subprocessdata/fd_status.py | 3 -
 Lib/test/test__locale.py | 24 ---
 Lib/test/test_asyncio/test_sendfile.py | 6 -
 Lib/test/test_asyncore.py | 2 -
 Lib/test/test_cmd_line.py | 2 +-
 Lib/test/test_curses.py | 2 +-
 Lib/test/test_fileio.py | 2 +-
 Lib/test/test_importlib/import_/test_path.py | 2 +-
 Lib/test/test_locale.py | 2 +-
 Lib/test/test_os.py | 14 +-
 Lib/test/test_posix.py | 7 +-
 Lib/test/test_pty.py | 4 -
 Lib/test/test_selectors.py | 2 +-
 Lib/test/test_shutil.py | 2 +-
 Lib/test/test_socket.py | 4 -
 Lib/test/test_strftime.py | 3 +-
 Lib/test/test_sys.py | 2 +-
 Lib/uuid.py | 5 -
 Modules/Setup | 4 -
 Modules/_ctypes/ctypes.h | 4 -
 Modules/_cursesmodule.c | 2 +-
 Modules/_multiprocessing/multiprocessing.h | 15 --
 Modules/_posixsubprocess.c | 11 --
 Modules/errnomodule.c | 23 +--
 Modules/mathmodule.c | 2 +-
 Modules/posixmodule.c | 65 +-----
 Modules/signalmodule.c | 2 +-
 Modules/socketmodule.c | 7 -
 Modules/termios.c | 8 +-
 Modules/timemodule.c | 9 +-
 Python/bootstrap_hash.c | 17 +-
 Python/fileutils.c | 3 +-
 Python/import.c | 3 +-
 Tools/freeze/README | 5 -
 Tools/i18n/pygettext.py | 3 +-
 Tools/pynche/Main.py | 2 -
 Tools/pynche/README | 2 +-
 Tools/scripts/nm2def.py | 2 +-
 configure | 285 +--------------------------
 configure.ac | 101 +---------
 pyconfig.h.in | 19 +-
 setup.py | 20 +-
 65 files changed, 91 insertions(+), 868 deletions(-)

Please don't.
Even if Oracle doesn't care anymore, the open source illumos community does.
We (illumos) share the same uname "SunOS" and depend on this support.
I have offered to host an illumos buildbot in the past and that offer is still valid.
At that time the testsuite did not pass and I could not figure out the fix yet.
If having this fixed is a requirement to keep illumos supported I will invest more time into this. I can also offer shell access to anyone interested in helping with this.

I looked at PyPI download statistics of the "six" module over the last 180 days (6 months), grouped by operating system name:
* SunOS: 3,975 downloads
* TOTAL: 590,727,298 downloads
SunOS is 0.0007% of all six downloads.
For comparison, the top 4 is:
* Linux: 91% (535,804,817)
* Windows: 4% (21,053,173)
* <empty system name>: 3% (18,695,360)
* macOS (Darwin): 3% (14,776,993)
Raw data of the top 14:
num_downloads,system_name
535804817,Linux
21053173,Windows
18695360,
14776993,Darwin
347090,FreeBSD
9759,Qnx
5350,Java
3975,SunOS
3178,CYGWIN_NT-10.0-14393
3177,CYGWIN_NT-10.0-17763
2505,CYGWIN_NT-10.0-18363
2263,AIX
2061,NetBSD
1891,OpenBSD

> We (illumos) share the same uname "SunOS" and depend on this support.
Which Python version do you use?
https://blogs.oracle.com/solaris/future-of-python-on-solaris mentions Python 2.7 and 3.4.

> Which Python version do you use?
Myself currently mostly python 3.8 via pkgsrc on SmartOS (one of the illumos distributions).
OmniOS ships 3.7: https://github.com/omniosorg/omnios-build/tree/master/build/python37
OpenIndiana ships at least 2.7, 3.5, 3.7.
The illumos build process also depends on python and was updated to support 3.9 two weeks ago: https://www.illumos.org/issues/13217 

Oracle moved solaris 11.4 to +- rolling release mode, last SRU is 26 from 20.10.2020 with month release cadence.
On another side, almost all informations are behind the Oracle paywall

I think Solaris Support is still important and I could invest more time on it.
About package downloads:
1. I routinely download packages in my laptop (Linux) and distribute them to a fleet of servers (Linux and Solaris) via ansible and similar. Many servers in intranets don't install packages directly via PIP.
2. Under OmniOS or SmartOS (Illumos distributions), many people use the system package manager to install Python packages, not "PIP". For instance, http://netbsd.2816.n7.nabble.com/WIP-commit-Upgrade-to-Mailman-2-1-34-td427426.html.
Buildbots: I used to manage a buildbot with OpenIndiana, but it didn't survived the GITHUB migration. I could provide now a SmartOS buildbot.
As a core developer, I do care about Solaris. I fully realize I have been quite inactive since the github migration. My fault. I could devote more time to the task.

I am using Python 3.8 installed via pkgsrc in SmartOS with some Zones running Python 3.9 self compiled code.
More about the downloads stats:
4% packages in windows: I am pretty sure that most windows programmers install packages via conda-like tools. Surely there is more that 4% of python programmers on windows, even more in machine learning and data science areas, where windows and MacOS X rule (apparently being only 7% of PIP downloads).
Even if the PIP download stats would reflect penetration, Solaris is ahead of NetBSD and OpenBSD together.

Hi! I'm a member of the illumos core team, and I'm also pretty keen for us to keep Python support! Some of our core OS build and packaging tooling is written in Python, and certainly applications like Synapse (Matrix) and Review Board are important to myself.
We currently provide a virtual machine for builds to the Go project that is wired in to their official CI/CD. I expect we can help out with a similar thing here!
I know some illumos distributions (OmniOS, OpenIndiana, anything with pkgsrc, etc) are maintaining some patches against the stock Python to fix failing tests, etc. Hopefully we can figure out how to get those things upstreamed and increase our participation there.

We at OmniOS (an illumos distribution) are in the process of upgrading to Python 3.9 and working on getting tests clean. We're in pretty good shape with a few local patches and only having to skip a few tests at the moment, and most of those patches should be suitable for integrating generally.
Some of the tests just need adjusting to be aware of the different platform (e.g. illumos does not support multiple SCM_RIGHTS messages in a single packet), some still need investigating to find the root cause, but the list is small.

Re: Downloads
OmniOS makes modules like 'six' available through its own IPS packaging system (which is written in Python) so installations won't show up pypi stats.
six is a core module on the platform so it is installed on 1000s of OmniOS machines (and then large numbers of SmartOS, OpenIndiana and tribblix ones too - all using the SunOS tag). The numbers aren't going to be in the same league as other platforms but the downloads stats definitely don't represent the illumos installation base and dependency on Python.

Like OmniOS, Oracle Solaris provides the 'six' (and many other) module prepackaged.
You can review a clone of the development repository at
https://github.com/oracle/solaris-userland/tree/master/components/python/six 

No, please continue supporting Illumos, I'm still using it. Illumos is still relevant on servers.

Between SmartOS, Illumos, and mainline Solaris, there is ample interest and support for ensuring that SunOS derivatives remain 1st class python platforms.
Platform genocide is both unnecessary and unwarranted.

Hello! I just want to lend my voice in favor of maintaining "Solarish" support as well, and offer what help I may for resolving issues.

Please do not drop support. 
Python is widely used in the "Solaris" community with most people downloading packages from Openindiana/Hipster or Joyent/SmartOS repos. Most "Solaris" users are not using Solaris proper.
The download stats published in this ticket is not a good representation of usage. Similarly most (Free|Open|*)BSD users install from their respective versions of ports.

No no no, please don't.
Apart from FreeBSD, illumos distros are the only really hard-core UNIX OS'es still freely available, the features taken into account. 
SMF, dtrace and several hypervisor types makes illumos really stand out.
I understand that there are resources that need to be assigned to maintaining Python on illumos/SunOS, but please reach out to their communities, maybe someone can help.

Please do not drop support for SunOS. 
We are happy to provide some hosting services on SmartOS/Illumos for building.

I'm another Illumos user that has crawled from under a rock ;-) to request not to drop Illumos support.

Please continue support for Solaris/IllumOS! For build resources on the most recent Solaris platforms you can contact opencsw.org.

Please continue support for Solaris/IllumOS!
This is very important for us.

Please don't drop Solaris support, we still use it to this day.

Please, keep support!

I'm an illumos user too, mostly SmartOS and some OmniOS.
I'm a heavy user of salt and thus phyton too, slowly prepping to get my stuff moved from 2.7 to 3.8 atm.
As mentioned above parts of the illumos build also use python and are moving to wads 3.9.
As mentioned I rarely use pip at all to install packages, nearly everything I need is available via IPS or pkgsrc depending on the distro.

Also, let me join in here. 
OpenIndiana hipster and all other illumos distributions will suffer if you drop the "Solaris" support. Just to get an idea which packages in a nearly default install depend on python:
pkg uninstall: Unable to remove 'runtime/python-35@3.5.9-202001.1' due to the following packages that depend on it:
 communication/im/pidgin@2.13.0-202001.4
 desktop/compiz/ccsm@0.8.16-202001.0
 desktop/time-slider@0.2.101-202001.116
 desktop/xdg/menu-editor/mozo@1.24.0-202001.0
 developer/build/onbld@0.5.11-202001.20038
 developer/clang-80@8.0.1-202001.0
 developer/ui-designer/glade@3.22.2-202001.0
 developer/versioning/mercurial-35@5.3.2-202001.0
 diagnostic/ddu@1.3.1-202001.40
 gnome/config/gconf@2.32.4-202001.8
 install/distribution-constructor@0.5.11-202001.1052
 metapackages/build-essential@1.0-202001.21
 package/pkg@0.5.11-202001.5543
 package/pkg/system-repository@0.5.11-202001.5543
 print/cups/system-config-printer@2.30.0-202001.3
 print/filter/hplip@3.19.12-202001.0
 release/os-welcome@1.0-202001.23
 service/gnome/desktop-cache@0.2.2-202001.7
 service/network/samba@4.12.5-202001.0
 system/file-system/zfs@0.5.11-202001.20038
 system/input-method/imf-startup@0.5.11-202001.3
 system/install@0.5.11-202001.1052
 system/network/avahi@0.7-202001.3
 system/network/avahi/gui@0.7-202001.3
 system/zones/brand/ipkg@0.5.11-202001.5543
 text/texinfo@6.7-202001.1
 web/server/apache-24/module/apache-wsgi-35@4.5.22-202001.5
Actually the package manager itself, installer, ZFS helpers, cups, the illumos build-system and and and all depend on python.

We, in danubecloud (https://github.com/erigones/esdc-ce) are relying on Python, too. Keep up the good work, folks :-)

I suspect the download stats are not a full indication of usage on "SunOS" based on download stats. The bits are preinstalled. I do use it frequently via Illumos. Please support the platform.
Regards,
Mike

I'm speaking officially for Danube Cloud, an advanced project which is open-source virtualization platform similar to Proxmox, XCP-NG, oVirt, Joyent Triton, etc. Our base platform is SmartOS and we have everything written in Python.
If you drop support for "Solaris", it will hurt our project a lot. Python has become heart of many projects and it should not limit itself to support just the mainstream platforms and OSes.
Thank you for everything you've done so far and I hope we can continue together.
Jan Poctavek
Danube Cloud
https://github.com/erigones/esdc-ce 

Let me add my voice to those who ask to keep Solaris support in Python going forward. We use SmartOS which is an Illumos and thus Solaris derivative.
We use Ansible extensively to automate our SmartOS deployments. We have a couple hundred VMs and 2 part-time volunteers on staff. We are extremely reliant on Ansible, and thus Python.
I have multiple blogs and a couple of django-based web sites that are running on SmartOS and we run a wide variety of tools that use Python as part of their mix.

It seems like two Python core developers (Ronald Oussoren and Jesús Cea Avión) are volunteer to maintain the Solaris support. Moreover, it seems like some people would like to provide a Solaris server to run a buildbot server. In this case, I would be fine to keep the Solaris code.
But it's not enough, please call for help:
https://mail.python.org/archives/list/python-dev@python.org/message/NYWF4DUPFYZSKUUZ3ZHOSBQCWAF4IIQO/ 

> But it's not enough, please call for help:
Please *read* my call for help

Why?? I use python on solaris in my every day toolchain and at work. 
There is no harm in keeping it supported, it's not hard. 
Please do not drop support.

Hi, here I am passing on several notes from the Oracle Solaris team:
- Oracle continues to develop and advance Oracle Solaris technology, and have committed to doing so for years to come. We release a new update (so called SRU) every month (https://blogs.oracle.com/solaris/oracle-solaris%3a-update-to-the-continuous-delivery-model).
- Python is essential for Oracle Solaris and actively worked on. In fact, we recently finished migration to Python 3.7 and integrated Python 3.9, which will be released to customers soon.
- Internally, we are performing daily testing for each Python version from 3.7+ and reporting any issues that are found* (fortunately, there are not many of them because Python works very well!).
- Python 3 is running for more than a year now on any machine running Oracle Solaris 11.4.
- Looking at six download statistics is very misleading because we are packaging Python and its modules in Solaris packages. This package is essential (meaning that every Oracle Solaris machine will have it installed). Also, we are caching archives internally, so unless customers download a newer version into a virtual environment, you won't see more than a few downloads from Oracle Solaris (which are then distributed onto thousands of machines running Oracle Solaris).
- We are looking at how to provide build bots running on Oracle Solaris.
- We are trying to be part of the Python community and also put back Solaris specific fixes (we provide patches for many of those issues reported).
- It is certainly much better (hopefully for everyone) to resolve any specific Solaris issues and help with the maintenance within the Python community than do this just internally as part of Oracle Solaris development.
*) everything reported by me are Solaris related issues
Jakub

I think the PR needs to be withdrawn. Users have spoken. There is zero need to cut them off.

Discussions are happening in this thread, including the requirements for supported platforms going forward:
https://mail.python.org/archives/list/python-dev@python.org/thread/VDD7NMEDFXMOP4S74GEYJUHJRJPK2UR3/ 

Dear Solaris Python fans (about 20 so far here): Here is the situation. There are 1000s of open issues on this tracker and at least 100s of open cpython PRs, and only 20-30 core developers, mostly volunteers, actively (depending on definition) merging PRs and maybe another 10 triagers helping to manage issues.
You all can help on issues by checking whether reported bugs still exist with current Python (3.8+) on current 'Solaris' (which includes what?). Searching open issues for 'Solaris' in 'All text' just returned 114 hits. About half were last touched over two years ago, and sometimes the last touch was inconsequential (a version or nosy change). I suspect many of the 114 are obsolete. For example, the last comment, five years ago, on #1471934, says the problem was fixed in Solaris 11.2. Does this mean the issue should be closed?
The bottleneck for merging PRs is reviewing PRs. We coredevs cannot do enough reviews ourselves. But any competent user can help. Reviewing has two components. First, does the patch fix the problem? Testing this requires a Github account and a local clone and ability to build a test binary. See devguide.python.org for more. Second, does the patch meet our standards of code quality. Solaris-specific patches likely change the C part of cpython, so C competence and understanding of PEP 7 is needed here.

Jakub: Would you mind to build the master branch of Python, run the test suite and post the tests results? In short:
git clone https://github.com/python/cpython.git
cd cpython
./configure
./python -m test -j0 -r
If possible, try to install dependencies (readline, lzma, etc.).
If there are failures, please copy them into a file, and attach the file to this issue.
It is to have an idea if it would be worth it to add a Python buildbot running on Solaris. If there are too many failures, it would be better to fix first most failures before considering to add a buildbot.

I think this is really a bad idea. I am using OpenIndiana in my classrooms and I teach Python! So if your drop Solaris support, it means I have to install a new supported OS on my many systems, to learn and teach many things, etc, This will make my life extremely difficult.

I ran the test and the results are attached (the first one is a complete test and the other one failed tests in verbose mode).
I checked the failing tests and divided them into several groups:
issues already reported:
 test_asyncio - reported and being solved here: https://bugs.python.org/issue38323
 test_posix - problem with return values, reported here: https://bugs.python.org/issue41839
 test_shutil - sendfile for Solaris was disabled in the library, but not in the test suite, which leads to the issues (I asked about reenabling here: https://bugs.python.org/issue41843; that would solve the issue)
these failures are probably related to our internal network settings (false positives):
 test_ssl, test_urllib, test_urllib2, test_urllib2_localnet
other:
 test_float - locale related *
 test_locale - locale related *
 test_re - most likely locale related *
 test_socket - known issues not yet reported upstream (not ready for acceptable PR)
 test_time - one locale related * and other not yet known
 test_tcl - yet to investigate
*) Locale related failures are due to wchar_t differences between the Linux world and ours. It's something we resolved very recently and have yet to rework it into an upstreamable form and report it.
It would be interesting to see Illumos results as well, because while also Solaris, there might be differences due to almost ten years of spit development.

Don't remove, it is still actively used by so many people. If the maintance overhead of 700 lines is a large burdern, then I'm happy to take on whatever work is required for it.

Jakub's results looks very familiar to me, having been working on python 3.9 on illumos.
For OmniOS, we currently skip these tests via --ignorefile:
# wchar_t related failures
*.test_re.ReTests.test_locale_compiled
*.test_re.ReTests.test_locale_caching
# illumos does not support multiple SCM_RIGHTS messages in a packet
*FDPassSeparate*
# These tests fail on illumos and the first consumes a significant
# amount of memory. Investigation required.
test.test_socket.SendfileUsingSendfileTest.testCount
test.test_socket.SendfileUsingSendfileTest.testWithTimeout
test.test_socket.SendfileUsingSendfileTest.testOffset
#
test.test_asyncio.test_sendfile.*
test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests.*
We are also carrying some local patches for the following. Several come from Solaris.
- Stop python detecting and using epoll() on illumos
- scheduling priorities can be < 0
https://github.com/citrus-it/omnios-build/blob/python39/build/python39/patches/mod-posix-sched_priority.patch
- differences in sendfile behaviour (improves the situation but is not complete)
https://github.com/citrus-it/omnios-build/blob/python39/build/python39/patches/mod-posix-sendfile.patch
- Enable sendfile for shutil.copy (mismatch between library and testsuite in terms of whether sendfile() is enabled on illumos)
https://github.com/citrus-it/omnios-build/blob/python39/build/python39/patches/mod-shutil-sendfile.patch
- Fixes for building the socket module (_XOPEN_SOURCE=600)
https://github.com/citrus-it/omnios-build/blob/python39/build/python39/patches/mod-socket-xpg6.patch
- Emulate clock_gettime(CLOCK_THREAD_CPUTIME_ID)
https://github.com/citrus-it/omnios-build/blob/python39/build/python39/patches/mod-time-threadtime.patch
- PTY patch
https://github.com/citrus-it/omnios-build/blob/python39/build/python39/patches/pty.patch
and a few others, not all of which are suitable for upstream.
https://github.com/citrus-it/omnios-build/tree/python39/build/python39/patches
With all of this in place, the headline test stats for OmniOS Python 3.9 are:
401 tests OK.
24 tests skipped:
 test_dbm_gnu test_epoll test_gdb test_idle test_kqueue test_msilib
 test_ossaudiodev test_smtpnet test_socketserver test_startfile
 test_tcl test_timeout test_tix test_tk test_ttk_guionly
 test_ttk_textonly test_turtle test_urllib2net test_urllibnet
 test_winconsoleio test_winreg test_winsound test_xmlrpc_net
 test_zipfile64
Tests result: SUCCESS
and, additionally, the dtrace tests succeed (we test them separately as they require elevated privileges).

Thanks Andy, good to know we are seeing the same issue!
We tried to fix sendfile differences in Python code before as well, but as you said, it was never 100% solved. Recently we finally fixed it in C and it was accepted (https://bugs.python.org/issue41687) and backported to 3.9 so you might/should be ok without the patch as well.
CLOCK_THREAD_CPUTIME_ID was issue for us as well but before the patch was accepted upstream, Oracle Solaris implemented it so it was no longer necessary. But the issue is still open https://bugs.python.org/issue35455 and knowing that others will use it, I will dust it off and finish it.
Knowing that Oracle and Illumos are facing the same issues, I am much more confident that our patches won't break Illumos. I will start upstream more of them right away.

I can understand the frustrations around dealing with minority platforms, but please remember that the illumos project (www.illumos.org) is basically the inheritor of problems around "Build on Solaris" for 3rd party software like Python. There are several OS distributions based on illumos that would be impacted by removing the ability to (easily) build Python. I'm confident we can find some people to help maintain build-bots etc. if that's what it takes. If you're still looking for such help, let me know and I'll ask on developers@list.illumos.org for volunteers.
Thanks! -GWR

People interested in helping Solaris issues should see my post above, msg380006.
Issue #35455, about thread time on Solaris, with a simple but non-trivial patch, was just closed as fixed after reviews from 2 coredevs and a 3rd person.
I presume Victor will close his proposed PR when there is a buildbot and additional action on issues. We have gotten new information that supports doing so.

Victor, are you going to close the PR?

Copy of my email sent to python-dev.
https://mail.python.org/archives/list/python-dev@python.org/message/46UUJ4J5YLCWF2JQMC5L7OIYG6PNQLRL/
Since I created the issue and the PR, and sent this email to
python-dev (one week ago), many Solaris and Solaris-like (ex: Illumos)
users replied that the operating system is definitively alive. I
didn't know that Oracle still ships new Solaris updates every month:
that's a good thing!
But this is not enough to support a platform. We would need proactive
contributors to fix known Solaris issues, but also fix new Solaris
issues (either regressions, or bugs newly discovered). We would also
need a buildbot to run the Python test suite on Solaris (or again, a
Solaris-like OS).
The good news is that Jakub Kulik started to fix some Solaris issues.
I understood that Solaris and Solaris-like operating systems do have
downstream patches on Python to fix a bunch of bugs. It seems like
some people want to push these fixes to Python upstream which is also
a good sign.
The other problem that I wanted to discuss is that fixing Solaris
issues require core devs (who merge PRs) accessing Solaris. If
contributors send patches and some core devs are fine with merging
fixes without being able to test them manually, I'm also fine with
that.
My first intent was to remove support for a definitely dead operating
system, but it seems like I was completely wrong (it's alive!). Thanks
to people starting to fix Solaris issues, I close my PR and I no
longer plan to drop Solaris support. I prefer to leave bpo-42173 open
for now, since people decide to use it as a place to collaborate on
fixing Solaris issues.
Once most tests will pass on the master branch, I also hope that
someone will set up a buildbot *and* fix issues discovered by this
buildbot. Sorry but just setting up a buildbot doesn't solve any
problem, it only increases the maintenance burden for people who
maintain the buildbot fleet. For example, we have two AIX buildbots, I
report bugs on bugs.python.org, but it seems like nobody is available
to fix them...
Overall, I'm quite happy with what is happening with Solaris! More
collaboration, issues being fixed in Python upstream. I just hope that
this work will continue next months. ;-)

This issue title is "Drop Solaris support". I no longer plan to drop Solaris support. I suggest to open new issues and continue the discussion there.

Gaige B Paulsen offered to set up a SmartOS (Illumos-derived) buildbot:
https://mail.python.org/archives/list/python-buildbots@python.org/thread/7HGPHD3WZG6V6NVP6EGQO6NHZ3DAPPXN/ 

I close the issue. Thanks for the constructive discussion and I hope that more and more downstream patches will be merged in Python upstream ;-)