-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Split pdata package by telemetry signal type #4918
Conversation
Codecov Report
@@ Coverage Diff @@
## main #4918 +/- ##
==========================================
+ Coverage 89.93% 89.96% +0.03%
==========================================
Files 183 183
Lines 11104 11104
==========================================
+ Hits 9986 9990 +4
+ Misses 892 889 -3
+ Partials 226 225 -1
Continue to review full report at Codecov.
|
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.
LGTM this is how I would envisioned to continue that PR.
LGTM to me as well. Only small question: do we want common aliases to be in |
This is a good question.
Maybe I missed something else? I'd prefer |
Works for me. |
ae0b1a6
to
7117b3c
Compare
Can you elaborate on this? I'm not sure I follow. |
If we choose this route, should we jump straight to this PR and skip #4833? I'm not seeing the benefit of it as an intermediate step. Is there something I'm missing there? |
I tried to outline the next steps towards moving from unified pdata to the new separate packages. To do that we need to update all the clients of pdata. There is no yet decision whether we will be splitting all other packages by the signal type. So there are two possible ways:
|
I would prefer granular changes as they are pretty much independent steps. Just to keep clean git history with smaller change sets |
7117b3c
to
9b87abc
Compare
For the sake of user clarity, we should support intuitive conventions Example - which is what this PR proposed and is implementing. So +1 on this PR. |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
971a734
to
6a68c81
Compare
I added a small usage example of the new pdata packages as further split of consumer package: #5086 I also added a PR with the alternative package structure and the same usage example: #5087 I think I like structure from this PR more because:
Let me know WDYT. I will also update more packages to show usage of both version more extensively. |
As mentioned in the other PRs, I think we agreed to not do this. Also if from the same repo we export conflicting packages I think we fail a bit the language pattern :)
This is nice indeed. |
I would agree on this one. Is this the only reason why you prefer #5087 over this PR? |
I disagree. I think it is less about whether there are multiple packages with the same package name within the repository and more about whether they are likely to be imported at the same time. What other packages would conflict with these names? |
c71caf5
to
fd63b56
Compare
It depends on whether we will be splitting other packages. If we split them, it'll be at least |
b59c1ab
to
321f935
Compare
As I described here, it's not required to change any clients to split the pdata package. We can split it right away. The only thing we need to decide is which package structure we are going to adopt. I updated all the core's code in this PR and #5087 to use new packages and deprecated the old one. There are few conflicts with existing |
321f935
to
ab7bf1f
Compare
ab7bf1f
to
e52bb60
Compare
Results of the poll from today's SIG meeting https://docs.google.com/document/d/1D_jK39GYkp9wAPgRoCYntnzq4LBs_YNnu64vXJGc9nI/edit#heading=h.oeev18el9qk1:
So I'm closing this PR in favor of #5087 |
This is the next change after #4833 following the approach outlined as Option 3 in this issue. It adds new aliases for pdata split into different packages by signal type. The following package structure is proposed:
Next steps:
Once all the steps are done the following package structure will be achieved: