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

Consider exposing 'read-env' #92

Open
cnuernber opened this issue Apr 17, 2021 · 2 comments
Open

Consider exposing 'read-env' #92

cnuernber opened this issue Apr 17, 2021 · 2 comments

Comments

@cnuernber
Copy link

Hey, I am building a graal native executable and part of its dependencies use environ.

The issue is that the defonce env gets compiled into that native executable and is initialized at build time (which is something we have to do for Clojure programs). I think that is unavoidable really but for our systems I would like to call read-env at runtime but it is private.

Would you consider making read-env public?

@SerhiiKozachenko
Copy link
Contributor

Hey, @cnuernber I also just faced this problem, what did you end up with?

I tried to use --initialize-at-run-time=environ.core option of the GraalVM native image, but that didn't work.

I would want to continue using environ, and seems like the #95 fixes it.

@cnuernber
Copy link
Author

I copied environ and exposed read-env. So we don't depend on this library any more. Then we have a system to save the program config to a variable that gets scanned by graal's compiler and hence saved as a static variable in the system and then use read-env to apply only the environmental changes to the static variable.

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