-
-
Notifications
You must be signed in to change notification settings - Fork 644
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
Remove the underlying implementation of anonymous-telemetry
#18952
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.
Yay simplicity
Co-authored-by: Eric Arellano <[email protected]>
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 generally in favor, but has there been discussion of removing this? Seems like something Maintainers should agree on
We've mentioned it informally, but also join in: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1683644499629429 |
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 generally in favor, but has there been discussion of removing this? Seems like something Maintainers should agree on
Agree it would be a good thing to have maintainers agree to this before landing, but see no issue to why we couldn't get that here? (and if it becomes a hot topic, may of course want to redirect longer discussions elsewhere)
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 am in favor of removing humbug as the implementation of anonymous telemetry, but I do wonder whether there isn't some other very simple web api we could use to report this same data, which might actually result in it getting consumed more often than the humbug data did?
One option that might reduce churn would be to leave all of the actual public infrastructure of anonymous telemetry in place (the subsytem, docs, etc), but to remove the recording backend. We would then schedule the deprecation of the subsystem for a future version, to leave room for another implementation (and the motivation to build it) to present itself.
Hmm I've thought of that as well @stuhood, so I'm in favor. Let me switch this to that. |
anonymous-telemetry
and remove humbug
anonymous-telemetry
Should we also remove |
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're not using it right now. I'm fine with removing the humbug-based implementation. Once we have something better, we can re-introduce it.
If a user has telemetry enabled and is using an older branch, and if we do not renew our telemetry storage solution, will those users have any issues? Do we need to cherry-pick this to old branches before we can fully sunset the telemetry service?
No, part of the guarantees is all forms of failure are silent. |
Since the consensus seems to be not cherry-picking this, I proposed #18959 as a focused fix for cherry-picking, and this one can then remove that workaround too.
Minor, but due to #12733 (or similar), this gives the same result before this change: So, we might want too confirm the change another way, e.g. (not sure if there's easier ways):
|
Oh duh lol |
I will always and forever +1 telemetry removal (even anonymous telemetry). I would also be a +1 for cherry picking this - and deprecating the current anonymous_telemetry field. I mean, it's "technically" a functionality change, but in practice - it's not end-user or development-user-centric functionality. But I'll defer to Pants convention on the cherry pick. |
Going to merge. Thanks for participating y'all. |
(updated PR with manual testing steps) |
…) (#18971) The release of urllib3 2 has caused issues with installing pants (e.g. it requires OpenSSL 1.1.1), so, for now, we can restrict to only working with urllib3 1.x.y and thus reduce how often people have to apply workarounds like `PIP_CONSTRAINTS=...`. I've verified that the wheel `METADATA` has `Requires-Dist: urllib3 (<2)`, and installing the wheel into a fresh venv _before_ uses `urllib3==2.0.2`, while installing the wheel _after_ uses `urllib3==1.26.15`. This patch is intended to be an option for a short term/focused work-around that is safe to cherry-pick back to older branches, while #18952 is the better fix (removes the use of urllib3 from the main wheel) but riskier, and thus might not be cherry-picked. Background: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1683644499629429
…) (#18973) The release of urllib3 2 has caused issues with installing pants (e.g. it requires OpenSSL 1.1.1), so, for now, we can restrict to only working with urllib3 1.x.y and thus reduce how often people have to apply workarounds like `PIP_CONSTRAINTS=...`. I've verified that the wheel `METADATA` has `Requires-Dist: urllib3 (<2)`, and installing the wheel into a fresh venv _before_ uses `urllib3==2.0.2`, while installing the wheel _after_ uses `urllib3==1.26.15`. This patch is intended to be an option for a short term/focused work-around that is safe to cherry-pick back to older branches, while #18952 is the better fix (removes the use of urllib3 from the main wheel) but riskier, and thus might not be cherry-picked. Background: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1683644499629429
This is the reason
requests
(and therefore other dependencies) is a dependency of Pants. This yields a smaller Pants footprint. Lastly, as Carina says in Slack:After:
We're keeping the subsystem in place so that we could swap in another implementation at a later date.