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

Dev mode #5

Open
effigies opened this issue Sep 18, 2019 · 1 comment
Open

Dev mode #5

effigies opened this issue Sep 18, 2019 · 1 comment

Comments

@effigies
Copy link
Contributor

Similar to #1, a lot of development tools may end up importing a library that uses etelemetry. For instance, in nipype, running make specs will call a script that imports nipype. It seems plausible that plenty of IDEs will also load the library.

For PyPI stats, developers won't tilt the stats so much, but if I'm using a tool that results in a lot of pings, I might be shifting stats by noticeable differences, at least in smaller projects. A development mode could either tag submissions so the server can distinguish, or set bounds on the client to avoid excessive reporting (e.g., suppress outputs for 10 minutes after calling).

Perhaps this doesn't matter for etelemetry purposes, and you want to get those reports as much as any other, but figured I'd bring it up.

@mgxd
Copy link
Collaborator

mgxd commented Sep 18, 2019

totally agree, we should actively try to reduce false positives where possible.

For the time being, one easy way to have developers avoid this could be using an envar (ETELEMETRY_NO_REPORTING or something) to avoid excessive pinging. But would be nice to think of a better solution to remove the burden from the developers..

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

No branches or pull requests

2 participants