Skip to content
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

Closed
t0yv0 opened this issue Oct 17, 2023 · 6 comments · Fixed by #2473
Closed

Remove ./pf go module #1445

t0yv0 opened this issue Oct 17, 2023 · 6 comments · Fixed by #2473
Assignees
Labels
impact/breaking Fixing this issue will require a breaking change kind/enhancement Improvements or new features resolution/fixed This issue was fixed

Comments

@t0yv0
Copy link
Member

t0yv0 commented Oct 17, 2023

Hello!

  • Vote on this issue by adding a 👍 reaction
  • If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

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:

  • pf and . are already released on the same cadence in practice, this makes it more obvious
  • eliminate a class of issues with accidentally misaligned versions of . and ./pf that do not compile or do not work together
  • simplify tooling for releases and upgrades

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

@t0yv0 t0yv0 added impact/breaking Fixing this issue will require a breaking change needs-triage Needs attention from the triage team kind/enhancement Improvements or new features labels Oct 17, 2023
t0yv0 added a commit that referenced this issue Oct 17, 2023
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.
@mikhailshilkov mikhailshilkov removed the needs-triage Needs attention from the triage team label Oct 18, 2023
@blampe
Copy link
Contributor

blampe commented Aug 21, 2024

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.

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 pf module directly, and then use a replace to point it at a local copy without the module. The only thing that changes is you no longer have a go.sum reference to the deleted module.

❯ diff -u go.mod-before go.mod
--- go.mod-before	2024-08-21 13:16:10
+++ go.mod	2024-08-21 13:21:46
@@ -2,8 +2,10 @@

 go 1.22.6

-require github.com/pulumi/pulumi-terraform-bridge/pf v0.42.1
+require github.com/pulumi/pulumi-terraform-bridge v0.0.0-00010101000000-000000000000

+replace github.com/pulumi/pulumi-terraform-bridge => /Users/bryce/src/pulumi-terraform-bridge
+
 require (
 	github.com/hashicorp/terraform-plugin-go v0.22.0 // indirect
 	github.com/pulumi/pulumi-terraform-bridge/v3 v3.89.1 // indirect


❯ diff -u go.sum-before go.sum
--- go.sum-before	2024-08-21 13:16:15
+++ go.sum	2024-08-21 13:21:47
@@ -6,8 +6,6 @@
 github.com/hashicorp/terraform-plugin-go v0.22.0/go.mod h1:mPULV91VKss7sik6KFEcEu7HuTogMLLO/EvWCuFkRVE=
 github.com/pmezard/go-difflib v1.0.0 h1:4DBwDE0NGyQoBHbLQYPwSUPoCMWR5BEzIk/f1lZbAQM=
 github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=
-github.com/pulumi/pulumi-terraform-bridge/pf v0.42.1 h1:IMn3MmvoO66iptcU5kBdun60PqwNJBJ20A4hD3AqkDE=
-github.com/pulumi/pulumi-terraform-bridge/pf v0.42.1/go.mod h1:SXxx1PJNNdGoD4/CxELgy0F46uzcTbDkz63DJsjIRXE=
 github.com/pulumi/pulumi-terraform-bridge/v3 v3.89.1 h1:FLQknb6r3r/uaj1XLbouFF88eF1Fk0h4JOVS9kHKDRY=
 github.com/pulumi/pulumi-terraform-bridge/v3 v3.89.1/go.mod h1:JAxygKR/XGW6zIv6iOP6sHAYjZ7OCtqU7j6Od1lUk38=
 github.com/stretchr/testify v1.9.0 h1:HtqpIVDClZ4nwg75+f6Lvsy/wHu+3BoSGCbBAcpTsTg=

The answer to "Should this be a module?" is almost always a resounding "No!"

Other instances where unnecessary go.mod files have made life harder than necessary for us:

Edit: I should also add if your module has a permanent replace directive (not just for local development) it's a strong sign that you would be better off with a single module.

@t0yv0
Copy link
Member Author

t0yv0 commented Sep 27, 2024

I'd very much like to do this but might need help, it is easy conceptually but there's some lift refactoring tests.

@VenelinMartinov
Copy link
Contributor

VenelinMartinov commented Oct 8, 2024

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 added a commit that referenced this issue Oct 8, 2024
Bumps the muxer to the latest version.

Contains a fix for provider debug attachment panic from June
#2088

#1445 would have
helped here
@blampe
Copy link
Contributor

blampe commented Oct 10, 2024

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.

blampe added a commit that referenced this issue Oct 15, 2024
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.
@pulumi-bot pulumi-bot added the resolution/fixed This issue was fixed label Oct 15, 2024
blampe added a commit that referenced this issue Oct 15, 2024
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.
@pulumi-bot
Copy link
Contributor

This issue has been addressed in PR #2473 and shipped in release v3.93.0.

@pulumi-bot
Copy link
Contributor

This issue has been addressed in PR #2473 and shipped in release v3.93.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
impact/breaking Fixing this issue will require a breaking change kind/enhancement Improvements or new features resolution/fixed This issue was fixed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants