-
Notifications
You must be signed in to change notification settings - Fork 64
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
Create Maps API key automagically in Kuviz #1082
Conversation
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.
Beyond the missing tests and so on, I added a couple of comments. Not needed to be tackled in this PR. If this is time sensitive, let's merge it and tackle everything else in a different issue.
""" | ||
def __init__(self, credentials=None): | ||
credentials = credentials or get_default_credentials() | ||
self._api_key_manager = _get_api_key_manager(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.
We should raise an error if we are not receiving the master API key here, because otherwise it won't work the API key creation. It could be responsibility of carto-python.
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.
Filtering the API keys with the one provided by the user to check if it is the master one? This also applies to the Kuviz creation, the user should use the master one.
I am not sure about it. Maybe we can catch Access denied
exceptions and remembering the user about using the master key?
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.
Anyway, the validation of the credentials is something to work on because we are not validating if the credentials are defined or not (we are doing the classical credentials or get_default_credentials()
, but not checking if we have credentials or not after that). Maybe we can create a task with both objectives
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.
cartoframes/viz/kuviz.py
Outdated
def _sync_layer(self, layer, table_name): | ||
layer.source.dataset.upload(table_name=table_name, credentials=self._credentials) | ||
layer.source = Source(table_name, credentials=self._credentials) | ||
warn('Table `{}` created. In order to publish the map, you will need to create a new Regular API ' |
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.
Every time you publish a map, you are we gonna get a bunch of warnings right? Even when we are creating the regular API key automatically...
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 think we should warn the client about that, don't you?
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.
If you publish a map with several layers, you'd get a bunch of warnings which actually might seem errors.
I think we could at most show the message once with a summary. It would be much better using a logger as well (but we are not there yet).
In any case, isn't the whole purpose of this PR to create the API key automatically? Why we still need to show this message?
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.
In any case, isn't the whole purpose of this PR to create the API key automatically? Why we still need to show this message?
You are right, the message is wrong.
Thinking about the rest, we are showing some messages (table creation), but not others (API key creation). Furthermore, our current messages seem like errors, so we could avoid them by now.
I have added a comment about that in the logging issue: #422 (comment) and I am going to remove the current ones.
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.
Quite comprehensive tests ✨
Fixed some typos
""" | ||
def __init__(self, credentials=None): | ||
credentials = credentials or get_default_credentials() | ||
self._api_key_manager = _get_api_key_manager(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.
cartoframes/viz/kuviz.py
Outdated
def _sync_layer(self, layer, table_name): | ||
layer.source.dataset.upload(table_name=table_name, credentials=self._credentials) | ||
layer.source = Source(table_name, credentials=self._credentials) | ||
warn('Table `{}` created. In order to publish the map, you will need to create a new Regular API ' |
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.
If you publish a map with several layers, you'd get a bunch of warnings which actually might seem errors.
I think we could at most show the message once with a summary. It would be much better using a logger as well (but we are not there yet).
In any case, isn't the whole purpose of this PR to create the API key automatically? Why we still need to show this message?
examples/05_publishing/01_publish_visualization_using_kuviz.ipynb
Outdated
Show resolved
Hide resolved
Upss sorry, just saw this wasn't in the kanban yet... I just got the notification and thought it was fine to review it 🙏 |
Co-Authored-By: Alberto Romeu <alrocar@users.noreply.github.com>
…frames into feature/magic-apikey-kuviz
Co-Authored-By: Alberto Romeu <alrocar@users.noreply.github.com>
…frames into feature/magic-apikey-kuviz
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 continue with acceptance. @elenatorro If there are any changes needed in the docs/examples let's add comments here and tackle them in a different PR.
Acceptance 🍏 Maybe I wasn't too comprehensive since I just validated the notebook actually does what it's expected to do. I'm merging this one. |
Solves: #731