Skip to content

Ability to use yaegi's unsafe.Symbols #11588

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

Open
2 tasks done
Rydez opened this issue Mar 6, 2025 · 5 comments · May be fixed by traefik/piceus#110 or traefik/plugin-service#69
Open
2 tasks done

Ability to use yaegi's unsafe.Symbols #11588

Rydez opened this issue Mar 6, 2025 · 5 comments · May be fixed by traefik/piceus#110 or traefik/plugin-service#69
Labels
area/plugins kind/enhancement a new or improved feature.

Comments

@Rydez
Copy link
Contributor

Rydez commented Mar 6, 2025

Welcome!

  • Yes, I've searched similar issues on GitHub and didn't find any.
  • Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you expect to see?

I expected to be able to use certain go dependencies in my middleware plugin.

Proposal

Create some way to configure traefik to run yaegi's i.Use(unsafe.Symbols). I'm happy to create a PR for this, but I'm unsure of the proper way to add this config item to traefik.

Why

I'm trying to build a middleware plugin which has quite a few go dependencies. One of these deeply nested dependencies is unsafe. I see here that this part of the standard library can be used. But looking in traefik (here) it looks like it's not being used whatsoever. I'm wondering if there's a clean way to add a yaegi config item to traefik for allowing the use of unsafe.Symbols in yaegi. Maybe through the static config of the middleware?

[EDIT]
Here's the @rtribotte #11589 (comment) that describes the procedure to follow.

@nmengin
Copy link
Contributor

nmengin commented Mar 6, 2025

Hey @Rydez,

Thank you for reaching out.
It looks like your problem is similar to the one described in another issue #10923.

I close this issue as a duplicate.

@Rydez
Copy link
Contributor Author

Rydez commented Mar 6, 2025

Thanks, @nmengin!

@Rydez
Copy link
Contributor Author

Rydez commented Mar 6, 2025

@nmengin after investigating the wasm middleware, It seems like yaegi would be a better experience. For example, the request context is preserved for yaegi, but in wasm the api.Request type doesn't have the concept of context.

With wasm, I'm also worried about the need to override the default transport to make http requests. I need to due further testing, but here https://pkg.go.dev/github.com/stealthrocket/net/http I'm seeing that:

Note that only the default transport (http.DefaultTransport) can be altered, other instances of http.Transport created by the program will default to use the standard library's net package, which does not have the ability to open network connections. Programs that create new transports must configure the dial function by setting the DialContext field to wasip1.DialContext. 

Which makes it seem that my dependencies which make http requests will need to be wasip-aware.

I'm wondering if you're against adding the ability to use unsafe with yaegi?

@Rydez
Copy link
Contributor Author

Rydez commented Mar 6, 2025

I went ahead and opened a PR to show a way this could easily be done: #11589.

@traefik traefik locked and limited conversation to collaborators Apr 6, 2025
@sdelicata
Copy link
Contributor

I'm reopening this issue that was closed by mistake.

I'm also updating the description with the @rtribotte #11589 (comment) that describes the procedure to follow.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area/plugins kind/enhancement a new or improved feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants