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
proposal: go:embed interpolate go env #48348
Comments
You can accomplish the same with build tags:
|
Making one go file per value indeed can work, and the IDE can resolve that just like it does now. It less code than a wildcard + scanning the files, but more files to maintain and drifty ones. Ex you need one of these per dimension, but they won't build on the current goos either. Build flagged source has a main issue even in smart IDEs which is drift is super easy. Ex someone renames Further, in the case where you have multiple expressions into the same Finally, while I didn't mention something besides {{goos}}, you could imagine others are useful too, {{goexe}} and while you can also do that with more build files it seems like it would get nasty fast. |
This proposal introduces another way of conditional compilation. It's a compile-time switch that only applies to parts of a source file, like an
|
It is an interesting way to think of this as "conditional compilation" and if we focused on the mechanics underneath the "go:embed" feature, that's probably an accurate way to find something to anchor a decision on. I would challenge us to think of the user experience and be specific. For example, go:embed does not allow arbitrary compilation of code. For example, if we accepted a template expression here besides '*' which is already supported... it wouldn't have the same risk or impact as a random if statement or adding a new variable. It would change the contents of that byte array, string or embed.FS, and that's quite a narrow scope compared to something like an ifdef, right? Personally I think spreading out "go:embed" selection across multiple build flagged files is a cure worse than the disease of using "*". I wouldn't recommend it, even if I might with actual code inclusions (like platform-specific functions or variables) IOTW, I don't really buy that we should think about go:embed expressions the same way as we think about including code statements. It is an interesting perspective, but I think that's more bottom up thinking vs UX centered, and I tend to bias towards the latter. |
Your points about UX and duplication seem valid, but the bigger question as far as I can tell is whether this kind of use case will be very common. I at least haven't encountered it to this degree. In a couple of cases cases I have needed to embed different assets per OS, such as an ICO icon for Windows and a PNG icon for Linux/Mac, where using two files seems entirely reasonable. The other side of the coin is what syntax you define, and whether it should apply to other |
Go programs should not be in the business of changing behavior based on arbitrary environment variables. Among other things, that would invalidate the build cache in unexpected ways. |
This proposal has been added to the active column of the proposals project |
Based on the discussion above, this proposal seems like a likely decline. |
No change in consensus, so declined. |
Right now, you can embed files with wildcards like so:
This is a bit more loose than necessary, as I'd like to be able to enlist go env variables
Something like this would significantly reduce the code needed to embed something platform-specific, as we would expect a go env variable to have only one value.
The text was updated successfully, but these errors were encountered: