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
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.
The text was updated successfully, but these errors were encountered:
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..
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.
The text was updated successfully, but these errors were encountered: