Navigation Menu

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

Python 3 support for Sentry or alternative solutions? #8806

Closed
wolph opened this issue Jun 21, 2018 · 10 comments
Closed

Python 3 support for Sentry or alternative solutions? #8806

wolph opened this issue Jun 21, 2018 · 10 comments

Comments

@wolph
Copy link
Contributor

wolph commented Jun 21, 2018

Over 4 years ago a similar issue was opened about Python 3 support in Sentry, at that time there was no forseeable end to the Python 2 support. That has changed some time ago, in about 1.5 years Python 2 maintenance will stop: https://pythonclock.org/

Since Sentry is a rather large application which would take a significant amount of time to (re)build its time to either start working on an alternative or work on the upgrade so a smooth migration is possible.

So my question is... should Sentry be ported to Python 3 or is it time to start building a Sentry alternative?

@max-wittig
Copy link

max-wittig commented Jun 22, 2018

Many projects will also drop python2 support earlier. Sentry may depend on some of them...
http://python3statement.org/

@mattrobenolt
Copy link
Contributor

At some point, it’s likely we will invest the efforts into doing so, but as of now, this is low priority and doesn’t affect the product Sentry at all. Things work and will continue to work just fine.

We have made lots of efforts so far in getting things compatible on both 2 and 3, but there’s still a decent amount of work left. And we’re fighting an uphill battle with little value in my personal opinion.

Right now, we run primarily on Django 1.6. The latest version of python is 3.6 with 3.7 around the corner. Django 1.x only supports up to python 3.5. So if we do successfully upgrade, we’re also still lagging behind in latest Python. To get to 3.6+ we need to get to Django 2.0+.

This is just a massive undertaking. We make small amounts of progress when we can.

@wolph
Copy link
Contributor Author

wolph commented Jun 22, 2018

Great to hear that some efforts are being made already, that eases my mind a little. I agree that for Sentry the change to Python 3 offers little benefit but once it loses support in 18 months we can expect distros to start dropping it as well. And that would be a problem :)

As for Python 3.5 vs. 3.6 and 3.7. As far as I'm aware there is no need to worry about forwards compatibility within the 3 series. So while it might not be officially supported, it's won't matter in real life scenarios.

@macher91
Copy link

Also you don't need go to Django 2.0+. Python 3.4+ is supported by Django 1.11.
Also as WoLpH write, if you upgrade sentry to 3.* you will be have small changes to upgrade python(or non changes).

Main reason why you should switch to python 3 is business perspective. In my company we wanted use sentry but we affraid that it will be not secure option. When python 2 lose support than will be no more security patches for ipython 2.

@benzkji
Copy link

benzkji commented Aug 6, 2018

Running on Django 1.6 isnt that reassuring as well, so a policy that commits on using a secure Django version would be nice as well (if you stay on the same version for very long, updating is always a pain, but if you do regularly, this will get easy!)?

And, January 1 2020 is in one year and four months. Anyway, really appreciate Sentry, and thanks for the uphill battle! With little value, maybe, but just very needed, as the product will probably just die otherwise.

@bunny1985
Copy link

Same here - I was trying to push Sentry into my organization, but without clear statement that it will not die after python 2 will be obsolete, its to dangerous for us.
So ... maybe a thing to reconsider?
I would not expect that you guys will drop what you are doing right now, but organizations needs clear statement that at some point you will switch.
At this point all we have is (form a previos issue)"99.9% sure this will never happen." and "at some point maybe".
and the question is real: is it time to start building a Sentry alternative?

@benzkji
Copy link

benzkji commented Aug 22, 2018

@bunny1985 so true. But guess what, there really is no alternative for them - running the service itself at https://sentry.io/ on python2 will not be possible anymore after a few months in 2020...or, again, an even more uphill battle...let's wait for that statement :)

@kamikaze
Copy link

Project management is so blind that it will be no surprise that Sentry will leave this planet after 2020. migrate or RIP

@dcramer
Copy link
Member

dcramer commented Dec 19, 2018

Python’s version has no bearing on Sentry nor does the version of Django we use. We’re capable of building software that works on safe technologies whatever they are. Constantly badgering us that your org won’t use Sentry because it’s on Python 2, or Django 1.6, or whatever piece of technology you’ve single handedly decided is best isn’t going to change anything - after all, our main focus is on building a reliable service.

We’ve been doing this for a long time and certainly won’t “disappear” in 2020. Nor will the other major internet properties that will continue to live on Python 2. That doesn’t mean we won’t move to 3, but it’ll happen when we feel it’s safe to commit to the change. If you cared you would see that there’s ample compatibility changes in the codebase that not only bring support up for newer versions of django (which we barely use, mind you), but also for future proofing much of our code on Python 3.

I’m locking this thread now as it’s not helpful to anyone.

@getsentry getsentry locked as resolved and limited conversation to collaborators Dec 19, 2018
@untitaker
Copy link
Member

Just to give an update to this, we have experimental Python 3.6 support that we ourselves do not run yet: https://forum.sentry.io/t/sentry-3-python-3/11457

All of this is just my opinion, but please stop assuming we don't know what we're doing. Comments like "if I were in your situation I would simply upgrade to 1.11" or statements about forward compatibility within Python 3 are not helpful to anyone. Having followed the internal conversations and efforts around this closely, I can assure y'all that it is much more complicated than proposed in this thread.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants