Skip to content
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

Multiple dotenv_path s #42

Open
DeveloperZoneIO opened this issue Aug 24, 2021 · 13 comments
Open

Multiple dotenv_path s #42

DeveloperZoneIO opened this issue Aug 24, 2021 · 13 comments

Comments

@DeveloperZoneIO
Copy link

DeveloperZoneIO commented Aug 24, 2021

It would be very nice to have the option to define multiple dotenv_path in the YAML. This is very useful for providing fields to many native layers. But currently it is only possible to provide a .env file for either the Android or the iOS Project, since dotenv_path cannot be defined multiple times.

@TatsuUkraine
Copy link
Owner

Hi. Thank you for proposal.

Could you explain more how it solves your issue? You expect to create 2 .env files with exact set of variables but in a different places?

@DeveloperZoneIO
Copy link
Author

Thanks for the fast response! Yes, that's exactly the thing I would like to have in there.

@TatsuUkraine
Copy link
Owner

Hm, not quite sure that I understand the problem. Have you tried package flutter_config to pass variables to iOS and Android from the .env file? Or dart defines? I just can't figure out how multiple paths solves the issue)

@DeveloperZoneIO
Copy link
Author

DeveloperZoneIO commented Aug 24, 2021

I'll give you an example:
I'm working on an App which uses the GoogleMaps SDK on both platforms (Android and iOS).
The GoogleMaps SDK requires to have the api key defined in the Manifest.xml for Android and programmatically on iOS.
So I did setup environment_config to use variables from the environment and generate a .env file inside the Android project, where gradle can access that file and do some manifest filed overrides. But in oder to access the apiKey in the iOS project i've to change the dotenv_path so that is is generated inside the iOS project.

The thing with flutter_config is that this will not work in the CI, since it needs a .env file and it also can not be used in gradle. Also I wouldn't like to have the secrets in a file in the repo.

@TatsuUkraine
Copy link
Owner

The thing with flutter_config is that this will not work in the CI, since it needs a .env file. But it is not a good idea to have the secrets in a file in the repo

Agreed, but you can generate .env with my package, and then use flutter_config to pass it's values to native layers (Android/iOS)

Is it possible to solve it with dart defines? I can assume you need just this value on the native layers, so in theory much easier solution will be pass it directly into the native layer with defines, rather than define env config yaml to generate .env and then read it on natives

Just trying to see the full picture

@TatsuUkraine
Copy link
Owner

TatsuUkraine commented Aug 24, 2021

If it's small info (and just a few keys) you can pass it during the build phase. Values could be taken from CI/CD env variables. And then it can be accessed in the android Gradle to inject into xml and in the iOS pre-build script to inject into plist if needed

@DeveloperZoneIO
Copy link
Author

Just trying to see the full picture

Yes, of course. totally understandable 🙂

Agreed, but you can generate .env with my package, and then use flutter_config to pass it's values to native layers (Android/iOS)

flutter_config is unfortunately not accessible in gradle, so this is no option.

Is it possible to solve it with dart defines?

Not really, since we have three stages in the app with different build configs and build config should also provide all secrets.
It is not about the google api key only but about key store passwords and much more secrets that are needed on the native layer. Also we search for a solution where we have all secrets in one place, the .env file, so that passing secrets via dart-define or other approaches do not suite the requirements.

Having the possibility to define multiple dotenv_path would also reduce the amount of dependencies to solve our current problem. Also using dart-define is very inconvenient while developing for developer who prefer working with command-line tool. (Thats not me 🤪 but I know some people who do not like to work with VSC UI)

@DeveloperZoneIO
Copy link
Author

And since environment_config is the best solution out there we would like to use it more often. But the current issue holds some of us back from using it more often. Unfortunately 😕

@TatsuUkraine
Copy link
Owner

TatsuUkraine commented Aug 24, 2021

flutter_config is unfortunately not accessible in gradle, so this is no option.

Oh, I thought it is - https://github.com/ByneappLLC/flutter_config/blob/master/doc/ANDROID.md#usage-in-gradle
I'm personally using dart defines for native env variables, haven't work with this package for a while)

Having the possibility to define multiple dotenv_path would also reduce the amount of dependencies to solve our current problem

What about instead of allowing multiple dot env paths, I add a possibility to override it with extension? Will it solve your problem?

@TatsuUkraine
Copy link
Owner

another option - sh script to run flutter with dart-defines and values from .env, I was thinking to create a package for this, but not quite sure if it's possible to make it in a way when it will be easy to install and use though

@DeveloperZoneIO
Copy link
Author

Oh, yes. An extension would definitely help us. This would mean that we would have to run the generator two times with different extension in order to have two .env files in the iOS and Android project, right?

@TatsuUkraine
Copy link
Owner

yes. I was just thinking that it will solve not just your case. For instance, if someone needs to have 2 different env files with a different set of variables, they can use extensions to define what env path is in each and define what variables should be exported there

@DeveloperZoneIO
Copy link
Author

Good point! I like the idea!

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

No branches or pull requests

2 participants