Fix OS's environment variable inheritance

[ulyssessouza]

What I did
This is meant to be an intermediate a solution for OS inherited environment variables in https://github.com/joho/godotenv

This fix relies on a fork of https://github.com/joho/godotenv on my repository https://github.com/ulyssessouza/godotenv
Also in an alternative branch on compose-go to point to this fork and implement the changes needed in the file parsing.

Related issue
Resolves #1917

[mat007]

Makes sense, is there a way we can hand binaries to the OP in #1917 to have confirmation it addresses his issue?

[mat007]

Also PR is still a draft.

[ulyssessouza]

@mat007 We don't have a proper way to hand a binary to contributor by now. What I can propose is to checkout and build it.
(The easy way would be using the release page as a pre-release, but it's not meant to serve this propose).
Obs: Just notice that the bump on compose-go is not to it's main branch so if it's bumped after that it will miss the fix

[mat007]

Obs: Just notice that the bump on compose-go is not to it's main branch so if it's bumped after that it will miss the fix

Ah, we would need to use our fork of godotenv in compose-go, do we want a PR there first?

[ndeloof]

replace don't apply on transitive dependencies, so this fix can't be applied on compose-go "only"

[mat007]

replace don't apply on transitive dependencies, so this fix can't be applied on compose-go "only"

Yes, we need it in both compose-go and compose-cli, but in this PR, if I understand correctly, compose-cli uses a fork of compose-go. I don’t think we want that, do we?

[ulyssessouza]

I just made a PR on compose-go to remove the replace and use the fork explicitly. Once it's merged in compose-go I will update this one to use it.

[mat007]

But can’t we use a replace in both projects?

[mat007]

Oh right, no we can’t see golang/go#30354
That makes sense, and it’s what @ndeloof was actually saying 😬

[mat007]

This needs to be updated now that compose-spec/compose-go#165 has been merged.

[ulyssessouza]

Close that in favor of #2002