Workflow with IntelliJ

[JurajMlich]

Hi there,

I'm evaluating the tool for a few of our Java/Kotlin projects and have been wondering how to set envkey up so that it works well with IntelliJ (or any IDE). As far as I'm aware, the only way to have envkey pass the env variables to the JVM is to use the envkey-source.

IntelliJ has various integrations for different environment (java, docker, python, various servers, etc), each enabling specific features for that platform. Unfortunately, I can't tell IntelliJ "hey, run this Java app and enable all the Java features but instead of using java -jar x use envkey-source -- java -jar x, there's no such option as far as I'm aware. So if I make it run envkey-source, it'll be just a generic run and all these "extra" features won't work (like out out of the box debugging for example).

Is there something I'm missing? I really want to use your product but if this can't be done, I'm afraid this will be a deal-breaker :(
Thank you very much! :)

[danenania]

Thanks for your post @JurajMlich. I'm wondering if integrating via Docker might be an option? It seems like this may be possible while maintaining Java debugging support: https://blog.jetbrains.com/idea/2019/04/debug-your-java-applications-in-docker-using-intellij-idea/

Otherwise, we are planning to prioritize a native Java integration before the end of the year which should resolve this.

[JurajMlich]

@danenania thank you for replying! I thought about docker but that would mean we'd have to rebuild the image after every change (or come up with some very not so pretty solution) so it's still not a very IDE-native solution.

A native Java integration could be a good solution, agree. But this problem is IMO a bit more general as you can't provide an integration for every language. So I think it could only be solved in two ways - plugins for IDEs or providing an option to generate a normal .env file (which I assume you don't really want to do as it goes against the other benefits of your system... but it could be useful for development envs for example).

What I pictured - having a deamon that would create the .env file on startup (and refresh the file on changes) and would delete it when the deamon stops. It would obviously leave the file behind if it was killed but for dev envs this could be good enough. Thinking about this - I may write such a script myself, I can actually use envkey-source to run it, so it would only dump the env variables and delete the file upon closing.

Any thoughts? And again, thank you for your time! :)

[danenania]

What I pictured - having a deamon that would create the .env file on startup (and refresh the file on changes) and would delete it when the deamon stops. It would obviously leave the file behind if it was killed but for dev envs this could be good enough. Thinking about this - I may write such a script myself, I can actually use envkey-source to run it, so it would only dump the env variables and delete the file upon closing.

For sure, that sounds like it could work. It's less ideal from a security perspective, but if you know you won't have anything sensitive in your dev environments, it could be ok. You could do this with a one-liner from envkey-source:

envkey-source --watch -- 'envkey-source --dot-env > .env'

And to delete the file when the watcher exits:

envkey-source --watch -- 'envkey-source --dot-env > .env'; rm .env

[danenania]

I should note this will also keep the .env file updated when there are changes.