-
Notifications
You must be signed in to change notification settings - Fork 1
upgrade to PyFCM 2.1.0, use google oauth lib to load credentials #7
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
base: main
Are you sure you want to change the base?
Conversation
|
|
||
| device = Device.objects.get(user_id=123) # get the device for the user you want to message | ||
|
|
||
| # To multiple devices |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note that the new API no longer supports multicasting
lukeburden
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @J-Priebe! Appreciate the PR.
A couple of questions, but generally looks good and I'll author a release soon.
testproj/testproj/settings.py
Outdated
| STATIC_URL = "/static/" | ||
|
|
||
| DEVICES_FCM_API_KEY = "oopwhoopdoop" | ||
| DEVICES_GOOGLE_SERVICE_ACCOUNT_INFO = {"foo": "bar"} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remind me why it's DEVICES prefix here but FCM_DEVICES in the test settings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No idea ;) old code, or perhaps you specify the prefix at a config level somewhere, and this is just ascertaining you can use different prefixes?
lukeburden
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @J-Priebe, appreciate your PR.
A couple of comments inline - but basically this looks great and I'm just hoping we can avoid the super tight dependency versioning you've added, as this can end up causing a lot of friction.
Also I saw at least one of your PRs to PyFCM has been merged now, so perhaps there are further adjustments?
Cheers!
setup.py
Outdated
| # and 1.5.x currently look good. | ||
| # https://github.com/olucurious/PyFCM/issues/285 | ||
| "pyfcm>=1.4,<1.6", | ||
| "pyfcm==2.0.6", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we loosen the pyfcm dependency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps. I'm a bit wary of the author's versioning. He isn't very active and there doesn't seem to be much oversight on PRs. I haven't looked too deeply at the test suites for this repo, and I've never released a library before so I'm not too certain of best practices here, but I think we'd want to ensure the method signatures and handling of mocked responses are consistent across a wide range of versions.
I have another PR in my head that I'd like to submit to PyFCM around optional arguments - maybe we can circle back to this in a couple weeks when I've got that merged in and there's a new PyFCM version released?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update: My second PR was merged and released in 2.0.7. However he hasn't authored any release notes since 2.0.1 when the breaking google API changes were addressed. I think we're betting off erring on the side of caution and pinning 2.0.7.
EDIT: NVM, my changes aren't in yet, we have to wait for 2.0.8 😑
setup.py
Outdated
| "pyfcm>=1.4,<1.6", | ||
| "pyfcm==2.0.6", | ||
| "django-konst>=2,<3", | ||
| "google-auth==2.22.0", # for loading credentials. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pyfcm has this as a dependency, so we can rely on that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's good practice to rely on a package dependency to do things outside that package. Since we're doing the loading of google credentials outside PyFCM, django-fcm-devices should have its own explicit dependency (which can be satisfied by PyFCM)
tox.ini
Outdated
| djangorestframework>=3.10 | ||
| django-konst>=2,<3 | ||
| pyfcm==1.5.1 | ||
| pyfcm==2.0.6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depending on your response to my earlier comments on reqs, may need adjustment.
|
Gah, I was mistaken and my changes to PyFCM haven't been merged in yet.. we need to wait for |
tox.ini
Outdated
| env_list = | ||
| checkqa | ||
| py{36,37,38,39}-dj{22,30,31,master} | ||
| py{38,39,310,311,312}-dj{22,30,31,32} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated tox to reflect that 3.6 - 3.8 are past end of life (3.8 recently, so I've left it in as pyenv still supports it, for now)
django master is now on 5.x, and actually this is broken by 4.x + due to changes in Signal args, so I removed it as well. 4+ is already disallowed in dependencies
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My sense is py3.8 is so broadly used, even though it's EOL it probably makes sense to support it for now.
We can add support for further Python and Django versions in a separate PR, kinda similar to what I've done over here for django-konst. I haven't closely looked, but my guess is there'll be backward compatible changes required so will justify a major release.
No rush on my end. Any idea if/when the maintainer will get to it? |
No description provided.