Conversation
src/lib.rs
Outdated
|
|
||
| // Modules that require file I/O - only available on native targets | ||
| #[cfg(not(target_arch = "wasm32"))] | ||
| pub mod batch; |
There was a problem hiding this comment.
so batching isn't available with wasm? why is that?
i guess this PR will require updates to the readme when it's finalized
There was a problem hiding this comment.
Currently, the problem with the batch module is that we are using the csv::Reader::from_path, but I think we can solve this by hiding only the file reading stuff behind the flag and for WASM add a parse function which will get the content of the csv from somewhere...
|
generally i would like to see less wasm-specific logic if possible. even if it means doing things in a slightly more complicated way. |
|
We should eliminate all environment variable reads from the codebase because it’s generally a poor pattern. Environment variables are process-level configuration and should be read once at program startup (or at a clearly defined boundary) and then passed down explicitly as arguments (or via a config object / dependency injection). This makes behavior deterministic, improves testability, and avoids hidden global dependencies. On UNIX-like systems (Linux, Darwin/macOS), an application receives its environment at process creation time: the parent passes an environment array into execve(), and a fork() creates a copy for the child. After the process has started, other processes cannot modify its environment; only the process itself (or code running inside it) can change it via setenv()/unsetenv() etc. So repeatedly calling getenv() during runtime rarely provides any meaningful “freshness,” and in multi-threaded code it can introduce subtle races if any thread mutates the environment. (which is another reason to treat environment variables as immutable startup configuration and to avoid reading them from within library code...) |
2 participants
No description provided.