-
Notifications
You must be signed in to change notification settings - Fork 56
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
Issues 109 #132
Issues 109 #132
Conversation
Anything we can do to help move this forward? |
@arnaudlimbourg If you'd like to provide another set of eyes to the documentation changes, that'd be helpful. I'm going to be pinging some people within Keen to get other reviews as well in the very near future. Thanks for the reminder about this! (My wife had a baby very recently so this was put on the back-burner for a bit.) |
@@ -441,3 +441,125 @@ def get_all_collections(): | |||
""" | |||
_initialize_client_from_environment() | |||
return _client.get_all_collections() | |||
|
|||
def create_access_key(name, is_active=True, permitted=[], options={}): |
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.
Was there a deliberate decision made to put this right in __init__.py
instead of doing something liked the Saved/Cached Query Interface? Just curious.
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.
The answer to all of these was, for the most part, to avoid deviating from the existing patterns I saw. The other answer is that I wanted to create the simplest path for users to run Access Key operations, which meant hiding the client (shoving it in __init__
like the basic queries) but also allowing them to work with a specific client in case they have multiple projects they are running in a single Python process.
To be honest though, I made that decision pretty lightly and could be persuaded to move it into its own interface. I don't like how monolithic that file has become.
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'm ambivalent, so whatever feels right to you.
keen/api.py
Outdated
|
||
return response.json() | ||
|
||
def _build_access_key_dict(self, access_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.
It seems this could be static, i.e. no need for the self
param
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 thought it was following a pre-existing pattern, and maybe it is but... we should probably run a cleanup pass through these functions that don't need self
at some point in the near future -- including this one.
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 expected the Codacity Code Analysis check to complain about it. Maybe that only runs on master? Not sure.
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.
It did complain, but the same pattern exists elsewhere. I'll plan on having this merged in about 18 hours, but before I do so, I'll probably remove this erroneous self
and leave other cleanup for later.
|
||
self._error_handling(response) | ||
return response.json() | ||
|
||
def _error_handling(self, res): |
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.
Not urgent, but it seems like _error_handling()
should return the JSON since we end up repeating that step anyway.
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 agree. This should be addressed at some point, if not now.
@@ -186,7 +186,7 @@ def get_collection(self, event_collection): | |||
@requires_key(KeenKeys.READ) | |||
def get_all_collections(self): | |||
""" | |||
Extracts schema for all collections using the Keen IO API. A master key must be set first. | |||
Extracts schema for all collections using the Keen IO API. A read key must be set first. |
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! I missed 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.
Thanks @BlackVegetable!
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 commented a few small things in the readme. Docs look great - love the update! ✨
README.rst
Outdated
|
||
.. code-block:: python | ||
|
||
import keen |
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.
maybe from keen.client import KeenClient
instead?
I'm not tied to that way, but for consistency?
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.
Basic queries don't require the client to be used. Eventually I'd like to make it clear that you use the client object if you need to use different projects in the same python process, but otherwise you can just use the keen package to run your stuff. If you think it would be clearer within the docs to use the Client (and make a mention of the root package being usable for this as well) I can make that change.
README.rst
Outdated
|
||
# Master key must be set in an environment variable ahead of time. | ||
|
||
# Create an access 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.
In the comment, could you add a link to permissions section in the docs? It would be handy since there's a lot of different permissions.
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.
Maybe this section? https://keen.io/docs/access/access-keys/#customizing-your-access-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.
Thanks. Will do.
README.rst
Outdated
|
||
# Replace everything but the key ID with what is supplied here. | ||
# If a field is not supplied here, it will be set to a blank value. | ||
# In this case, no options are supplied, so any options will be removed. |
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.
"any" -> "all"
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.
Will fix.
README.rst
Outdated
keen.update_access_key_full(access_key_id="ABCDEFGHIJKLMNOPQRSTUVWXYZ", name="Strong_Bad", is_active=True, permitted=["queries"]) | ||
|
||
|
||
Create Scoped Keys (Deprecated) |
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.
Maybe deprecated in bold to make it more obvious. Another option is to move in Legacy/Deprecated section
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.
Good suggestion. For now I'll bold it. Later I'll likely do as you suggest with a dedicated section for such.
I'm going to look into the time cost of adding unit tests for these in a couple of days. So this won't be merged until at least then. |
This does not include docs yet.
Changelog and cutting a new version.
This API will now support specific updates of access key names, options, and permissions. It also supports adding and removing some permissions from permission lists without requiring the user to replace the entire permissions list every time with exactly the end result he or she desires.
More tests. I've broken these tests out into their own file. An item of followup work this presents is to move the helper function and using a constant for a url prefix pattern to the remainder of the tests as well, but I feel that is beyond the scope of this already large issue. friendlier imports for non2.7 2.6 hates format without numbers
5882aac
to
734b111
Compare
def test_update_access_key_full(self, post): | ||
# The update tests have a significant amount of logic that will not be tested via blackbox testing without | ||
# un-mocking Keen's API. So this is the only test that will really cover any of them, and not even very | ||
# well. |
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.
All of these tests seem to only make sure the URL is generated properly and that the client/api regurgitate the response that's given to the mock. This gets good CC numbers, but isn't really doing too much in terms of being more certain it'll work with the real back end. I realize that's how all the query tests and most of the existing tests in general are, and it's out of scope for this PR, but I wonder if we shouldn't have a push a to do some validation on the payload generated like we do in test_update_full_saved_query()
and friends (see commit c4e3cae). If that seems like a good idea, I think it'd be worth filing an issue.
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.
Yeah, I'm definitely not a fan of these tests as they are presently constituted. This repo definitely would benefit from some test enhancements.
keen/api.py
Outdated
|
||
return response.json() | ||
|
||
def _build_access_key_dict(access_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.
This is really a static method, so it could have the @staticmethod
decorator, but maybe that's not necessary since this isn't meant to be called from outside the class, but in either case it's strange that this is invoked with self.
in several places below when it doesn't take the self
param.
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.
Oh, yeah, that's a little weird. Lemme fix that.
We will no longer support python 2.6 or 3.3. Neither is being used heavily with this library according to pip data, and both are EOL (2.6 since 2013!)
Added support for access keys. Do we need to bump the version number before merging this?