PyPI has the stable releases (versions that we believe are production ready). The master branch that you have linked above has work-in-progress support for Python 3. A large amount of work has been done towards Python 3 support and it is shaping up, but a significant Python 3 bug was found and fixed only about a week ago (#1054). More testing is needed before it can be considered production ready.

Why are these issues closed? The README says _Supervisor is known to work with Python 2.4 or later but will not work under any version of Python 3._ which means that #1060 and #1070 should not be closed.

Why are these issues closed? The README says Supervisor is known to work with Python 2.4 or later but will not work under any version of Python 3.

You are quoting the README of the current stable release version of Supervisor 3 (file). That version's README states that version's requirements.

The next major version, Supervisor 4, will include Python 3 support. This is the master branch in git. That version's README has been updated to indicate Python 3 support.

Is there a roadmap for the version 4 release? There seem to be no open issues on Python 3. Is there a way one can help in testing the current git branch?

Me too I am ready to help testing

@tcwalther @palmkevin Thanks for offering to help test. It would be very helpful if you could try to exercise the master branch under both Python 3 and 2, trying as many options and commands as possible, and reporting back. You can report back in either "I found x bug" or "I used it for x hours and exercised x features and didn't find a problem". Both would be helpful.

Several people have reported it works on Python 3 but it's clear to me from the bugs I found afterward that those people were not testing it very rigorously. For example, #1054 is a major feature of Supervisor and should have been reported. I just started typing the commands alphabetically and the first one I tried didn't work at all.

There has been a lot of progress made towards Python 3 support in the last few months. At this moment, I'm not aware of any Python 3 specific bugs which is why there are none in the tracker. It finally works enough that I have started running it under Python 3 now. I'd like to make a Python 3 compatible release. However, people depend on this software on production servers, so it's important that we have confidence that it actually works. Reports of successful testing would help.

Some basic testing of the master branch shows it seems to "work" at least a bit :) Will test it for a while and post any issues we find here...(@tcwalther and I are in the same gang).

To second @jkp, we're testing this in our team at work (we're on the same team). We don't use any sophisticated commands but only run supervisord -c some_config_file in the foreground as the entrypoint in a Docker container. We'll report back if we find any problems.

@mnaberez IMHO if testing is needed more than porting the code, it could be helpful to release alpha/beta/rc releases, so one does not need to fetch supervisor from git.

Are we any closer to a release? We'd very much like to use Python 3.

Please consider releasing a beta version on PyPI so that people can test Python3 compatibility in an easier way.

Many thanks.

A pre release on PyPI will helps a lot, thank you.

Please consider releasing a beta version on PyPI so that people can test Python3 compatibility in an easier way.

You should be able to install the master branch with pip using a single command (see VCS Support). We'd appreciate if you used this method, or a git checkout, to save the maintainers the extra work of packaging non-stable releases that will only be used by testers.

More Python 3 specific bugs have been reported and fixed recently (e.g. abef0a2be35f4aae4a4edeceadb7a213b729ef8d).

You are quoting the README of the current stable release version of Supervisor 3 (file). That version's README states that version's requirements.

The README and the online documentation (for the current stable release) says:

Supervisor is known to work with Python 2.4 or later but will not work under any version of Python 3.

These words are still a bit misleading to me (it actually frightened me and made me fear whether I should use Supervisor). I thought Supervisor (as vs. Supervisor 3) would never support Python 3. Luckly, it does not seem to be case....

@adah1972 The issue here is that there are no Python3 trove classifiers on https://pypi.python.org/pypi/supervisor so when users go to PyPI, it tells them that Supervisor _only_ runs on legacy Python.

The issue here is that there are no Python3 trove classifiers on https://pypi.python.org/pypi/supervisor so when users go to PyPI, it tells them that Supervisor only runs on legacy Python.

The Supervisor project only releases stable versions to PyPI. There is not currently a stable version of Supervisor that supports Python 3. Attempts to add Python 3 support have been made and we are much closer, but bugs in the Python 3 port continue to be found. Another one that broke major functionality was found earlier this month.

The README and Trove classifiers that you see on PyPI are correct for the latest stable version. The Trove classifiers were updated in setup.py for the Python 3 branch, and will be added to PyPI when a stable release of that version is made.

I would argue it would suffice to say:

Supervisor is known to work with Python 2.4 or later but it does not work under any version of Python 3.

It sounds really strange and confusing to say it will not.

Hey @mnaberez ,

I'm working with @palmkevin on the same project. We downloaded supervisor v4.0.0-dev0 and hosted it on our private pypiserver.
We are using it since about 2 months in our development environment and since a few weeks now at some client production environments. We did not face any problems so far.

We communicate with the supervisor via xmlrpc and use the following functionalities:

• shutdown
• startProcess
• stopProcess
• reloadConfig
• getProcessInfo
• getAllProcessInfo
• getState
• tailProcessStdoutLog
• readProcessStdoutLog
• getSupervisorVersion

Knowing this, I hope that we can encourage you to publish a first release of your package to pypi.

@henkesde92 Where did you get v4.0.0-dev0 from? I don't see that there is a tag or a branch for it.
Are you just using the head of the master branch?

More issues running on Python 3 have been found and tagged. In at least one case (#1178), the web interface stops working completely. Any help patching these issues would be appreciated.

@mnaberez Now that https://github.com/Supervisor/supervisor/pull/1187 is merged, are we close to getting a release? Even a beta/rc upload would greatly assist us,

It would help to get some focus on #1110 which I sense is fixed but it is the only open issue with a ___python 3___ label.

Is there a possibility of releasing a beta or rc version of supervisor to PyPI? I work on an open source project that uses supervisor extensively (https://github.com/ansible/awx), and we're closing in on Python3 support, and this is the _one_ remaining item holding us back. If a release were available on PyPI, we'd end up adding it to our expansive integration test matrix where we deploy and test our project across a variety of distributions.

I'd be glad to help dig into any remaining open issues (like
https://github.com/Supervisor/supervisor/issues/1110) that relate to py3 support and help push this across the finish line.

1110 Seems to happen on legacy Python too but it would certainly be helpful to find its root cause.

@mnaberez Could you please perhaps release a beta? It would help us immensely in testing Python 3 support.

@mnaberez,

An source project I work on (https://github.com/ansible/awx) has recently started testing HEAD of this repository in our builds, as we're working on support for py3-only distros. We run a very thorough nightly integration test suite across multiple Linux distributions. We use various supervisorctl commands and also make some use of RPC: https://github.com/ansible/awx/blob/devel/tools/docker-compose/supervisor.conf

So far, we haven't noticed any regressions in our testing of installs that run supervisord under Python 3.6.6.

We'd love to ship the next version pointed at a 4.0.0 beta rather than having to fork a specific git SHA of this repo.

We'd love to ship the next version pointed at a 4.0.0 beta rather than having to fork a specific git SHA of this repo.

This project does not release unstable versions to PyPI (noted above). Please do not ship production software using an unstable version of Supervisor (git sha or otherwise). If it was suitable to be used with production software, it would be released as a stable version. I think we are close but we are not there yet. There are a number of alternative programs that do what Supervisor does. If you cannot use a stable version of Supervisor, I would recommend choosing an alternative rather than risk a production environment on an unstable version.

@mnaberez,

Given that there seem to be a number of people in this thread doing _exactly_ this in production (and reporting no problems), and that there are no _notable_ open issues related to python3 in the tracker (there's https://github.com/Supervisor/supervisor/issues/1110, though it seems difficult to reproduce, low in severity, and specific to the usage of supervisorctl tail), at what point would you consider supervisor stable in python3, and worthy of a release? Is there some tangible set of criteria holding this back?

Given that there seem to be a number of people in this thread doing exactly this in production (and reporting no problems)

There have been people using Supervisor on Python 3 since 2014. For nearly all the time since, some have insisted quite vocally on this issue tracker that it runs fine. One of the most surprising ones for me was #1054. After years of claims it worked, an entire command was completely broken for the default configuration. There were similar issues with basic functionality like logging being very broken after years of success reports as well. So, while I appreciate and listen to reports of success, I may not weight them as heavily as I might if I had not had these experiences.

and that there are no notable open issues related to python3 in the tracker (there's #1110, though it seems difficult to reproduce, low in severity, and specific to the usage of supervisorctl tail)

The issue tracker has been mostly clear of Python 3 bugs only for only a short time, and it's possible that the bad file descriptor bug is only one manifestation of a bigger problem. I think at least that one needs more investigation before its scope or severity can be understood. There are also a bunch of issues tagged "help wanted", and I'd like to review those to be sure they're existing issues and not caused by changes on master, since some of the tracebacks on those are from master.

at what point what you consider supervisor stable in python3, and worthy of a release? Is there some tangible set of criteria holding this back?

I will try to review issues mentioned above again (bad file descriptor and help wanted), and also do some more rigorous testing, before it is pushed out. I am not the only committer capable of releasing this software, but I am the most active lately. I am one of the main authors of Python 3 patches on this project − I want a stable, Python 3 compatible release myself. At the same time, I want to have good confidence it won't take down a bunch of production websites, or generate a storm of new support issues. As I said above, I think it is close, but I wouldn't recommend running an unstable version of Supervisor in production.

then it can be released as beta (4.0.0b) on PyPI and even marked as Python 3 only using PEP 440 version specifier

setup(
    ...
    python_requires='>=3',
    ...
)

that way:

• all people wanting to use supervisor in Python 3 project will get much easier access to it, while it will still will be marked as considered unstable (in fact, pipenv for one, will not install beta unless explicitly configured to)
• more users (python 3 crowd) -> more features tested -> more confidence in Python 3 support
• current (Python 2) users won't be affected negatively

Personally I believe it should be quicker to triage issues being reported by new Python 3 users than wait for project owner/contributors to find sufficient amount of time to think of and test every possible scenario.

I would also like to note that seeing how Python 2 EoL is closing in (2020 Jan 1), Python 3 support is no longer an option, but requirement to keep this project alive, which is why I propose this solution.

The current coverage is at 89%: https://travis-ci.org/Supervisor/supervisor/jobs/476482824 bumping it to 95-99% would make you feel more comfortable to make a release? :thinking:

Patches to add test coverage are very welcome and would help raise confidence.

Desperate for a Python 3 support release, please... :)

Shouldn't the documentation be updated to say it's not available yet on python 3? or modified to show how to install it on a python 3 system?
unable to install supervisor on python 3 #1205

Shouldn't the documentation be updated to say it's not available yet on python 3?

The documentation for the current release version (3.3.5), which is published at supervisord.org, already says the following:

http://supervisord.org/introduction.html#platform-requirements
"Supervisor is known to work with Python 2.4 or later but will not work under any version of Python 3."

@henkesde92 Where did you get v4.0.0-dev0 from? I don't see that there is a tag or a branch for it.
Are you just using the head of the master branch?

@stevecj There is no tag or branch, it's on master, but the version number comes from setup.py which in turn reads it from supervisor/version.txt.

Closing this issue... It has been two years with almost no progress.

With just 295 days left until Python 2 end of life, this port is not going to happen in time.

@cclauss Perhaps there's no progress because it already works? I don't really understand why it isn't just packaged up for Python 3 and let the users use it and report issues as they are discovered? Surely that's one of the best ways to progress open-source software? Just letting the project die because nobody has the confidence to release a Python 3 version seems precious. A lot of hard work has obviously gone into this project.

FWIW, I've been using "4.0.0-dev0" with Python 3.5 for almost 12 months without any issues affecting me. However I admit I'm not testing all functionality, but it seems good enough to at least let the community start using it properly.

@mnaberez @cclauss Why do you object to releasing a beta version? You are actively discouraging users from testing Python 3 support by doing so as many orgs have compliance policies that make pulling from GitHub verboten.

This should be re-opened, as well.

Reopening since there still seems to be significant interest in this issue.

I’d say to step out of the “we only release stable versions” box and release a public alpha or beta version on pypi for the py2 -> py3 transition for the sake of this fantastic software.

This way you let the users decide to use alpha or beta releases and everyone knows what this terminology means.

Testing will be much easier for a lot of users and progress can be made in a short term when issues are added.

This way you let the users decide to use alpha or beta releases and everyone knows what this terminology means.

For most of its life, this project used a confusing versioning scheme. It was largely before my involvement with the packaging so I can't answer why. Stable releases had weird alpha/beta names like "3.0a3" or "3.0b2". Maybe they were intended as alpha/beta initially but they went on for years and were stable -- they had no significant issues and no BC breaks between them that I can remember. Versions with these names were even packaged by major distributions as stable. This very long history makes it difficult for us now to effectively communicate actual non-stable releases to existing users.

@mnaberez,

It looks like the last example of this (at least, from what I can tell in PyPI) was https://pypi.org/project/supervisor/3.0b2/

...which was nearly 6 years ago now. It also coincides with the move from supervisor2 to supervisor3, so the notion of pre-releases are a major versioning scheme that users should be familiar with, historically.

Could this potentially be addressed by a mailing list post explaining that a new alpha/beta/rc version has been released with official support for Python3 (including instructions on how to report any issues found?) Maybe calling it out very explicitly somehow at http://supervisord.org?

It seems to me like there are a number of people in this thread that are _already_ shipping production software using 4.0.0dev. Distributions are even packaging it from (I assume) HEAD.

https://koji.fedoraproject.org/koji/buildinfo?buildID=1203704

As a maintainer of open source software packages myself, I'd think this situation would be much less desirable than just distributing a pre-release, hearing directly from users, and fixing any bugs that exist.

@mnaberez Since the main concern is that stable versions used to be postfixed with a or b, could you please maybe use rc for actual pre-releases?

Again, many people are blocked on this 🙁

...which was nearly 6 years ago now. It also coincides with the move from supervisor2 to supervisor3, so the notion of pre-releases are a major versioning scheme that users should be familiar with, historically.

It used the weird a/b versioning scheme for all releases from about 2007-2011. It wasn't just some pre-releases.

Maybe release candidate rc would be better? Again, 2007 - 2011 was 8+ years ago.

@mnaberez The current version in master works fairly well with Python3, the community just need a release, although it's not perfect. It has full sense if the bug is holding this also appears in Python2 as some people points out.

All my fellow Plone community members and I guess the Pyramid ones are also eager to have it. Please, can you release it? An alpha would be perfectly fine.
Thanks a lot!

/cc @mcdonc @tseaver @stevepiercy @zupo @gforcada @pbauer @jensens @tisto

There never will be perfection in software. Supervisor is nearby, although there are open bugs in the issue tracker. To get things done it would be good to either mark the issues using an additional label such as "release blocker" (together with existing "help wanted"?) or (maybe better) use Githubs milestone feature, so people from the communities and companies with dev-skills using supervisor can tackle the problems and supply patches.

Currently the major problem for most people is not stability, but missing Python 3 release. A release is different from installing via VCS and can be packaged and distributed differently, fitting into current operations workflows. So, even if I repeat myself here, this uncertainty is a major problem.

@sneridagh the only maintainers on PyPI are @mcdonc and @mnaberez. Others can do nothing to release Supervisor on PyPI.

The core developers for Pyramid release alpha and beta versions, and it works well for us. We communicate releases through the usual channels: mailing list, Twitter, and README.

I don't see any issue with doing similar with Supervisor, and I think it would be beneficial to its further development. Heck, there might even be another maintainer lurking to share the burden.

Even we tried using the current master version. And it works just fine.
I am hoping this can be released as a beta package as we can use it directly rather than forking the repo and installing manually. I am going to host this package soon on a new PIP repository. Many of you can pull the pip package from there itself. Will update here soon.

I am going to host this package soon on a new PIP repository. Many of you can pull the pip package from there itself. Will update here soon.

A quick search of PyPI shows that at least one person has done this already:

https://pypi.org/project/supervisor-lrn/

Note: the author of this package is not involved with the Supervisor project. I have not downloaded or checked this package.

Closing in favor of the Python 3 compatible fork https://pypi.org/project/supervisor-lrn/

@cclauss seriously?

Ok, it's a pity but after more than 10 years using supervisor, we will switch to use pm2 or systemd.

So long, and thanks for all the fish.

I really don't understand the way the project maintainers have decided to
go about this. It's really a pity, whatever. The community is only asking
for a beta release to help testing and finalise python 3 support. Instead,
you point people to a fork.
I'll switch to something else as well.

On Sun, 24 Mar 2019, 2:44 pm Víctor Fernández de Alba, <
[email protected]> wrote:

@cclauss https://github.com/cclauss seriously?

Ok, it's a pity but after more than 10 years using supervisor, we will
switch to use pm2 or systemd.

So long, and thanks for all the fish.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Supervisor/supervisor/issues/1060#issuecomment-475960800,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGU8E33aSZ3ocMQoP7evXh7WWEq4Gv_ks5vZ4E1gaJpZM4SInJR
.

Please stop closing the issue @cclauss. Clearly there is interest from both the community and @mnaberez.

@cclauss seriously?

Ok, it's a pity but after more than 10 years using supervisor, we will switch to use pm2 or systemd.

@cclauss, the person repeatedly closing this ticket, is not part of the Supervisor project. He is able to close it because he originally opened it.

Since there is still an active discussion here, I'm going to reopen it (again).

@mnaberez ok, that caused a bit of confusion, I thought he was in charge too. Maybe we should move to another issue.

What is the blocker that is holding you for the release then?

@mnaberez And the same discussion in this ticket repeated already many times and is not heading into a (positive) direction.

Maybe you and some fellow maintainers could explain or reconsider your point of view on this issue and then close it?

Several users and other OSS maintainers already asked here for an official rc release. Now someone not related to the supervisor project did it. I don’t think this is beneficial for the Supervisor project, but understandable if you are not doing it.

It's really a pity, whatever. The community is only asking for a beta release to help testing and finalise python 3 support. Instead, you point people to a fork.

Please note that I pointed out the existing third party package only in response to another user commenting about creating a package. My intention was only to save that person from doing work that had already been done.

Maybe you and some fellow maintainers could explain or reconsider your point of view on this issue and then close it?

I intend to release an official Supervisor 4.0.0 package with Python 3 support within 2 weeks. The release is unlikely to be called alpha/beta for the historic reasons noted above, but may be called an rc as suggested by @ofek, @ryanpetrello, and others. However, it's been several months since I made the stability comments above, and no new Python 3 issues were reported since. I've also been using it during that time and have not had new issues. Given all that and the number of people reporting it works for them, it may simply be called 4.0.0. I will close this ticket when it is released to PyPI.

What is the blocker that is holding you for the release then?

There is not currently a blocker for this, other than I'd like to first make a 3.4.0 feature release that I have already started on. I intend to do that next week, and 4.0.0 the following week.

Please keep this open, our projects really need this to happen too.

Supervisor 4.0.0 (PyPI package; supports Python 3.4+ and 2.7)