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
Swap order of encoding.TextUnmarshaler and encoding.BinaryUnmarshaler #58
Comments
Hey @gust1n - thanks for opening an issue. Of course, it's technically possible to switch the order, but I'm worried about how switching the order might impact someone who is behaving on the current behavior (binary before text). Is there a reason this shouldn't be considered an upstream bug in I know it's not ideal, but you could also wrap a custom type and define type AddrPort netip.AddrPort
func (p *AddrPort) EnvDecode(val string) error {
return p. UnmarshalText(val)
} I'm definitely open to the change, but there doesn't seem to be clear guidance from Go on the "order" in which to test unmarshalers, and this feels like a corner case for this particular type. |
Hehe I thought you would say this (not wanna risk others relying on the current order) which totally makes sense. And I can for sure open an upstream issue too! However, when talking to some colleagues, we figured in the case of this library, it's probably more common to unmarshal text than binary, given that it's main use case is configuration (most often input from humans). Given that reasoning perhaps unmarshaling text should come first? |
Okay - let's do it. Do you want to put together a PR? |
Sure, will fix! |
Since the input parsed by envconfig is most often configuration written by humans, it makes sense to test unmarshaling as text before any other formats. Also JSON should be more common than binary, so this commits sets the order to: 1. envconfig.Decoder 2. encoding.TextUnmarshaler 3. json.Unmarshaler 4. encoding.BinaryUnmarshaler 5. gob.GobDecoder and adds tests to very that order. Closes sethvargo#58.
Since the input parsed by envconfig is most often configuration written by humans, it makes sense to test unmarshaling as text before any other formats. Also JSON should be more common than binary, so this commits sets the order to: 1. envconfig.Decoder 2. encoding.TextUnmarshaler 3. json.Unmarshaler 4. encoding.BinaryUnmarshaler 5. gob.GobDecoder and adds tests to very that order. Closes sethvargo#58.
Since the input parsed by envconfig is most often configuration written by humans, it makes sense to test unmarshaling as text before any other formats. Also JSON should be more common than binary, so this commits sets the order to: 1. envconfig.Decoder 2. encoding.TextUnmarshaler 3. json.Unmarshaler 4. encoding.BinaryUnmarshaler 5. gob.GobDecoder and adds tests to very that order. Closes sethvargo#58.
Since the input parsed by envconfig is most often configuration written by humans, it makes sense to test unmarshaling as text before any other formats. Also JSON should be more common than binary, so this commits sets the order to: 1. envconfig.Decoder 2. encoding.TextUnmarshaler 3. json.Unmarshaler 4. encoding.BinaryUnmarshaler 5. gob.GobDecoder and adds tests to very that order. Closes #58.
Since the input parsed by envconfig is most often configuration written by humans, it makes sense to test unmarshaling as text before any other formats. Also JSON should be more common than binary, so this commits sets the order to: 1. envconfig.Decoder 2. encoding.TextUnmarshaler 3. json.Unmarshaler 4. encoding.BinaryUnmarshaler 5. gob.GobDecoder and adds tests to very that order. Closes sethvargo#58.
We're transitioning to using the Go 1.18
netip.AddrPort
with go-envconfig parsing it from a string. We noticed a small corner case though, that some addresses don't fail on the binary unmarshalinggo-envconfig/envconfig.go
Line 521 in befaf9a
So e.g.
"239.255.76.67:7667"
would succeed (not error) when unmarshaled as binary (resulting in[3233:392e:3235:352e:3736:2e36:373a:3736%6]:13623
but e.g.127.0.0.1:11311
would fail and fall back to using the TextUnmarshaler, resulting in a properly decoded IPv4 address.Could we swap the order so the unmarshaling as text happens before the binary one?
The text was updated successfully, but these errors were encountered: