Skip to content

Conversation

laurazard
Copy link
Member

Make detect.InitContext public as opposed to only available through the use of contexts from appcontext so that downstream users (e.g. buildx) can keep the OTEL context utils without having to use appcontext - see: docker/buildx#2184

Make `detect.InitContext` public as opposed to only
available through the use of contexts from `appcontext`
so that downstream users (e.g. buildx) can keep the OTEL
context utils without having to use `appcontext` - see:
docker/buildx#2184

Signed-off-by: Laura Brehm <laurabrehm@hey.com>
@laurazard
Copy link
Member Author

cc @thaJeztah @crazy-max

Copy link
Member

@crazy-max crazy-max left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, ptal @jsternberg

Comment on lines 16 to 18
func init() {
appcontext.Register(initContext)
appcontext.Register(InitContext)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering if we need to keep the init, as that would be dead-code if appcontext is not used (but it will remain a dependency due to it being imported) 🤔

(have not looked how / where it's imported though).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I thought about making other changes to appcontext/this package for that but had concerns about that possibly silently breaking things for other downstream users. If we do that, we should do that together with other changes to make sure we don't silently break, or clearly call it out.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(side note, but I really hate inits for this reason, it's much harder to reason about and figure out the blast radius of changes like this)

Copy link
Collaborator

@jsternberg jsternberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. My preference for the future is that we make an effort to refactor the tracing code so we're not seeing buildx or other docker utilities depend so heavily on buildkit for tracing utilities and improve the buildx code to have a less ambiguous way of configuring tracing, but this seems like a good way to handle the current problem without making the blast radius too large.

@thaJeztah
Copy link
Member

@jsternberg with this function exported, do you think it would make sense to move the init to a separate package? (do you know what code paths depend on that init?)

(trying to see if we can get appcontext out of the dependency tree, to make it "crystal clear" if it's not used in code)

Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let me LGTM because the other bits can still be worked on in a follow-up 🤞

@jsternberg
Copy link
Collaborator

@thaJeztah I don't know too much about it, but I assume it can probably be moved to another package.

@laurazard
Copy link
Member Author

little ping, maybe we can get this one in and then open up another to move the init elsewhere so we can discuss that there?

@tonistiigi
Copy link
Member

Per latest comments in docker/buildx#2184 , I don't think that PR needs this anymore.

@laurazard
Copy link
Member Author

Closing based on discussion in docker/buildx#2184

@laurazard laurazard closed this Jan 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants