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-2020.0.1.1' due to the following packages that depend on it:

  communication/im/pidgin@2.13.0-2020.0.1.4
  desktop/compiz/ccsm@0.8.16-2020.0.1.0
  desktop/time-slider@0.2.101-2020.0.1.116
  desktop/xdg/menu-editor/mozo@1.24.0-2020.0.1.0
  developer/build/onbld@0.5.11-2020.0.1.20038
  developer/clang-80@8.0.1-2020.0.1.0
  developer/ui-designer/glade@3.22.2-2020.0.1.0
  developer/versioning/mercurial-35@5.3.2-2020.0.1.0
  diagnostic/ddu@1.3.1-2020.0.1.40
  gnome/config/gconf@2.32.4-2020.0.1.8
  install/distribution-constructor@0.5.11-2020.0.1.1052
  metapackages/build-essential@1.0-2020.0.1.21
  package/pkg@0.5.11-2020.0.1.5543
  package/pkg/system-repository@0.5.11-2020.0.1.5543
  print/cups/system-config-printer@2.30.0-2020.0.1.3
  print/filter/hplip@3.19.12-2020.0.1.0
  release/os-welcome@1.0-2020.0.1.23
  service/gnome/desktop-cache@0.2.2-2020.0.1.7
  service/network/samba@4.12.5-2020.0.1.0
  system/file-system/zfs@0.5.11-2020.0.1.20038
  system/input-method/imf-startup@0.5.11-2020.0.1.3
  system/install@0.5.11-2020.0.1.1052
  system/network/avahi@0.7-2020.0.1.3
  system/network/avahi/gui@0.7-2020.0.1.3
  system/zones/brand/ipkg@0.5.11-2020.0.1.5543
  text/texinfo@6.7-2020.0.1.1
  web/server/apache-24/module/apache-wsgi-35@4.5.22-2020.0.1.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.