Is it possible to load environment data from the host machine into a lustre process? I am bundling the app using lustre/dev build app so i can't really use any serverside libraries. I'm wondering if there is some sort of way to compile environment variables into the app on bundling sort of like how NEXT_PUBLIC works for NextJS where .env files prefixed with NEXT_PUBLIC are included in the bundle
#Load environment data in lustre process
limber glade
solid vault
mm no i dont think this is possible right now
could you open an issue in dev_tools i think this is a great idea
limber glade
will do
solid vault
in the interim you could write a little codegen program i guess
limber glade
yeah i wonder what the best solution would be, the obvious solution is the docker way eg.
gleam run -m lustre/dev build app -e MY_VAR=value
but it seems like it would be hard to enforce typesafety
solid vault
they would always be strings
oh i guess you mean like
how do you actually refer to them in code
limber glade
yup but thats the case more often than not with env anyways
limber glade
how do you actually refer to them in code
yeah
because you would need to get the lsp to work with you codegen
another solution is doing a pattern match for $MY_VAR in each string and replacing it but that is a terrible idea
solid vault
in elm its just a separate program you run to generate an Env.elm
https://github.com/jaredramirez/elm-constants/tree/master we'd probably just do the same
limber glade
yeah just generating a env.gleam is probably best
solid vault
i want to expand dev tools to include some codegen bits anyway so it seems like a good starting point
limber glade
so you get lsp after one run
solid vault
gleam run -m lustre/dev gen env
the first time, and then it would run automatically during dev and build
limber glade
sounds good
I'll leave this here for people who just want a simple solution in the meantime that you can use in docker/ci
echo "pub fn get_env() { \"$1\" }" > ./src/env.gleam
@static spoke 👀
static spoke
What would this do?
limber glade
Changing behaviors between development and production in a lustre application. Eg. switching api urls from localhost to a production domain
static spoke
And what would the generated function look like?
Sorry I'm really new to all of this 🙇
limber glade
I think just a simple Option maybe if you'd want to be thorough so
// env.gleam
pub fn get_env()
{
Some("Input env")
}
or something similar to that
alternative if the input is trusted a string would probably suffice
and since it's codegen one function per env would probably be nice
so
// env.gleam
pub fn get_db_host_env()
{
Some("mysql")
}
pub fn get_db_name_env()
{
Some("default")
}
And why can’t your program read an env var?
limber glade
Because it's a built lustre bundle so it's only running on the client
Since it's clientside you can't really read serverside info
static spoke
```
gleam run -m lustre/dev gen env
```
the first time, and then it would run au...
And how would it know which env variables to generate getters for?
limber glade
if the need to type what env variables should exist then maybe using custom types would be best
type Env {
Env(db_host: String, db_name: String)
}
this would solve having to know what env variables to generate but i don't know wether this is possible with the current gleam compiler eg. loading arbitrairy types at runtime as lustre dev_tools probably would have to do
solid vault
And how would it know which env variables to generate getters for?
any env vars that start with LUSTRE_
and it would generate a module of constants
LUSTRE_ENV=development LUSTRE_API_URL=whatever LUSTRE_WIBBLE=wobbly gleam run -m lustre/dev gen env
would generate
// src/env.gleam
pub const env: String = "development"
pub const api_url: String = "whatever"
pub const wibble: String = "wobbly"
it should also load .env automatically, with preference for .env.development when running lustre/dev start and preference for .env.production when running build
limber glade
If it's possible i'd also like to have the ability to input env variables through the cli as only having a .env is limiting when doing things like dockerization
solid vault
yup for sure
vars would load in this order: cli vars > .env.{development|production} > .env
static spoke
Ok I can do it!!
neon wagon
Is this the best design?
There’s no way to replicate it without codegen
If it was passed in to the program at the start or otherwise loaded the same mechanism could be used for all lustre programs, rather than more drift between programs using the dev tools and not
I always had the goal of avoiding the JS thing of having magical tooling being mandatory and having big unresolvable differences between each Gleam project
And lustre is moving the other way
static spoke
How could we go about this without codegen?
neon wagon
In Elm this would be called flags
Data is on the page and it gets passed in
Also means one system for all inputs so you can dynamically generate data too on the backend
solid vault
flags and env vars are unrelated to one another, many elm projects would use both
neon wagon
They are very much related to each other
They are external inputs to a program
And prior to the rise of compilers in frontend there wasn't a distinction
If you do want to introduce more lock-in for lustre dev tools I think it makes it more of a priority to work on the deployment related issues of the dev tools as there's more things the programmer will have to replicate without them in order to deploy their application once it is ready