You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm developing an API using Deeplake. The API can be called by different users, each user can specify its own Activeloop token which is used in the API like this:
So, it creates a file ~/.activeloop/reporting_config.json as soon as we are using a non-public organisation through a specific token not defined in the environment variable ACTIVELOOP_TOKEN.
Previously, the reporting config was only created when the token came from the environment variable:
But, the content of reporting_config.json is designed to specify only one username/client id. So, if different users call my API, this file will be overwritten by each different user leading to an inconsistent state.
If I understand well, this configuration is only used to send bug reports to Activeloop, so potentially the bug reports could be wrong in such case.
In conclusion:
could we customize the location of this configuration (it is similar to this issue: [FEATURE] Move directory ~/.activeloop Linux #2545), for example to have different configurations for the different users? Or at least the report configuration should support several users.
is it possible to easily deactivate the bug reporting for specific users in the same way we are able to specify a token? For now, the consent to send bug reports is not explicit and set to True by default without possibility to easily modify it in my use case.
Use Cases
No response
The text was updated successfully, but these errors were encountered:
We're currently working on some larger changes to our configuration handling, and improving the .activeloop directory handling is part of that. So the fix will be coming, but not a quick fix on it's own.
As you mention, the username setting in there is really only used for the activeloop usage reporting scenario at this point. We've been cutting down usage of it recently (the commits you pointed to are part of that) and the reporting is all that's left.
Since any reporting we do from that data is in aggregate, cases where the username is wrong ends up not really impacting the results significantly, which is why cleaning up that last usage of the username in there wasn't a priority. But, we will get to it and I'll leave this bug open until we do.
If you'd like to opt-out of the reporting for whatever reason, we look for the consent field in the reporting_config.json file and setting that to "false" will stop anything from being sent. That setting would apply to all the users on your system, since it's a global file. But if it's hard for you to set that, don't worry if the data is slightly wrong. And as part of our general config handling improvements we'll have additional ways of setting that which will hopefully work well for you too.
Description
I'm developing an API using Deeplake. The API can be called by different users, each user can specify its own Activeloop token which is used in the API like this:
Since the version 3.8.21, the
DeepLakeBackendClient
has been modified like this:deeplake/deeplake/client/client.py
Lines 78 to 82 in db90455
So, it creates a file
~/.activeloop/reporting_config.json
as soon as we are using a non-public organisation through a specific token not defined in the environment variableACTIVELOOP_TOKEN
.Previously, the reporting config was only created when the token came from the environment variable:
deeplake/deeplake/client/client.py
Lines 76 to 80 in 05852b7
But, the content of reporting_config.json is designed to specify only one username/client id. So, if different users call my API, this file will be overwritten by each different user leading to an inconsistent state.
If I understand well, this configuration is only used to send bug reports to Activeloop, so potentially the bug reports could be wrong in such case.
In conclusion:
True
by default without possibility to easily modify it in my use case.Use Cases
No response
The text was updated successfully, but these errors were encountered: