-
Notifications
You must be signed in to change notification settings - Fork 43
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 ./pf go module #1445
Comments
We have a bit of an automation gap around releases to keep these up-to-date. My preference would be to remove ./pf module if we can take a breaking change here #1445 instead of automating, doing manually for now, to keep referencing the right bridge module from the ./pf module.
Go will only use the dependencies it needs, so there is no cost to doing this. Quite to the contrary, things become significantly more straightforward without the overhead of the extra module! I suspect this line of thinking arose due to the way pu/pu exports a large chunk of the AWS SDK as part of its integration helpers, so consuming it tends to blow up indirect dependencies. But again this doesn't matter if a project doesn't actually consume the AWS SDK. It's easy enough to confirm this locally by standing up a project that imports the
The answer to "Should this be a module?" is almost always a resounding "No!" Other instances where unnecessary Edit: I should also add if your module has a permanent |
I'd very much like to do this but might need help, it is easy conceptually but there's some lift refactoring tests. |
I had a go at this: #2358 but lost steam with the tests, it's quite some refactoring. Would be happy to help if we pick it up again. |
@VenelinMartinov I'd suggest scoping this down to only removing modules and otherwise leaving the existing code as-is. Ensuring that still builds and behaves as expected is enough work on its own. I took a swing at that here #2473 Then in a followup you can start consolidating, deprecating things, etc. Edit: But Ian raises a good point that this is the "most breaking" option for consumers. |
This removes three unnecessary modules: * pf/go.mod * x/muxer/go.mod * testing/go.mod And three unnecessary test modules: * pf/tests/go.mod * pkg/tests/go.mod * x/muxer/tests/go.mod This is intended to be merged with #2477 and #2480, which combine to make this a no-op for existing consumers. Refs #1445.
This moves `pf`, `testing` and `x/muxer` under `pkg`. This will allow us to restore modules at those paths in order to not break existing consumers. More specifically, the new import paths are: `github.com/pulumi-terraform-bridge/pf` → `github.com/pulumi-terraform-bridge/v3/pkg/pf` `github.com/pulumi-terraform-bridge/x/muxer` → `github.com/pulumi-terraform-bridge/v3/pkg/x/muxer` `github.com/pulumi-terraform-bridge/testing` → `github.com/pulumi-terraform-bridge/v3/pkg/x/testing` (I put this under `x` since `testing/x` is the only package in this module) Refs #1445.
This issue has been addressed in PR #2473 and shipped in release v3.93.0. |
This issue has been addressed in PR #2473 and shipped in release v3.93.1. |
Hello!
Issue details
Consider removing pf/go.mod Go module and folding it into the top-level ./go.mod module. This is a breaking change for consumers that will need to adjust their Go references.
The benefit of doing this is simply managing providers:
The downside is that dependencies from
./pf
including Plugin Framework dependencies will be added to all bridged providers even if they are not using Plugin Framework internally. This may be an acceptable cost to pay.Affected area/feature
The text was updated successfully, but these errors were encountered: