Remove the underlying implementation of anonymous-telemetry#18952
Remove the underlying implementation of anonymous-telemetry#18952thejcannon merged 8 commits intopantsbuild:mainfrom
anonymous-telemetry#18952Conversation
Co-authored-by: Eric Arellano <14852634+Eric-Arellano@users.noreply.github.com>
benjyw
left a comment
There was a problem hiding this comment.
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 |
kaos
left a comment
There was a problem hiding this comment.
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)
stuhood
left a comment
There was a problem hiding this comment.
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 humbuganonymous-telemetry
|
Should we also remove |
cognifloyd
left a comment
There was a problem hiding this comment.
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.