Thanks for the reply Jose! The dependency order makes sense as an issue with my initial thought - one other approach is that a project could define its own method of configuring IEx if there were a hook to allow that - looking at the IEx.Evaluator I was able to make a pretty small patch to allow for this type of configuration by adding a new public function and extending the `loop` function
```elixir @spec load_dot_iex(pid, pid, String.t()) :: :ok | :error def load_dot_iex(evaluator, server, path) do ref = make_ref() send(evaluator, {:load_dot_iex, server, ref, self(), path}) receive do {^ref, result} -> result after 5000 -> :error end end ... defp loop(%{server: server, ref: ref} = state) do receive do {:eval, ^server, code, counter, parser_state} -> {status, parser_state, state} = parse_eval_inspect(code, counter, parser_state, state) send(server, {:evaled, self(), status, parser_state}) loop(state) {:fields_from_env, ^server, ref, receiver, fields} -> send(receiver, {ref, Map.take(state.env, fields)}) loop(state) {:value_from_binding, ^server, ref, receiver, var_name, map_key_path} -> value = traverse_binding(state.binding, var_name, map_key_path) send(receiver, {ref, value}) loop(state) {:variables_from_binding, ^server, ref, receiver, var_prefix} -> value = find_matched_variables(state.binding, var_prefix) send(receiver, {ref, value}) loop(state) # NEW RECEIVE CASE TO LOAD A DOT IEX FILE PROGRAMMATICALY {:load_dot_iex, ^server, ref, receiver, path} -> next_state = load_dot_iex(state, path) send(receiver, {ref, :ok}) loop(next_state) {:done, ^server, next?} -> {:ok, next?} {:done, ^ref, next?} -> {:ok, next?} end end ... I think that combining this overriding the default mix task would allow for the type of configuration that I was hoping to achieve - or if there is desire for this functionality a small change could be incorporated into mix to do this as a feature using `project.cli()[:iex_configuration_file]` or something of the sort. If you don't think any of this is necessary in Elixir proper I can move my work towards something at the project level, but wanted to see if there was any interest in upstreaming this concept On Thursday, June 6, 2024 at 11:40:51 AM UTC-5 José Valim wrote: > Hi Chris, thanks for writing. > > > • will be used when `iex` is run from that directory not in the context > of that mix project > > The reason this happens is exactly because IEx starts before Mix, so we > can't use Mix to configure IEx. And I think that will get in the way of > your proposal too. I hope this helps narrow down a bit the paths to explore. > > On Thu, Jun 6, 2024 at 4:23 PM Chris Miller <camil...@gmail.com> wrote: > >> Currently we use the `dot-iex` file to configure an iex shell. The >> `dot-iex` file that gets loaded is the first of these three things that is >> found >> • --dot-iex PATH command line argument supplied to the iex command >> • '.iex.exs' file in the directory that iex is run from >> • '.iex.exs' file in directory found in the env var "IEX_HOME" OR the >> users home directory >> >> The issue I am facing currently is that project level shell configuration >> is hard to manage in a way that achieves these goals >> • will apply configuration when running a shell in the context of a >> particular (mix) project >> • will allow for a developer to apply their own particular customization >> • does not require any additional scripts / arguments to start the project >> >> Existing partial solutions for a project level iex configuration >> >> • create and commit a `.iex.exs` file for the project >> -- PROS: >> • the file will be loaded when `iex -S mix` is run >> • configuration can be specific to the project as it is part of the >> source code written for the project and tracked through whatever svc is used >> -- CONS: >> • does not allow for an individual developer to include their own >> configuration as expected (you could add an >> `import_if_avaiable(".dev.iex.exs")` line to the project level `.iex.exs` >> file to allow for this extension, but it makes the file name arbitrary and >> could cause some confusion) >> • will be used when `iex` is run from that directory not in the >> context of that mix project >> >> • create a project specific configuration file and use the --dot-iex >> command line arg >> -- PROS: >> • does not interfere with running `iex` outside of the context of the >> mix project >> • can load additional configuration files by include >> `import_if_avaiable` statements >> -- CONS: >> • Requires including the --dot-iex arg when running the `iex -S mix` >> command, which is prone to being forgotten, this could be wrapped in a very >> simple start script, but you would still need to remember to run that (I >> work with a largish number of elixir services and having individual start >> scripts or args per project can be cumbersome to remember) >> >> I think an ideal solution would be a way to configure a mix project to >> load a particular configuration file that will be loaded when the >> IEx.Evaluator starts IN ADDITION to the existing `dot-iex` file options. I >> believe this would allow for maintainers of a project to normalize some >> shell configuration while still allowing developers the full ability to add >> their own configuration while also keeping the workflow of starting the >> shell more standardized across projects. >> >> A secondary goal might be that this could be incorporated into releases >> as well so that the `./bin/project remote` and similar commands could also >> load some particular configuration >> >> Thanks in advance for any thoughts you had, and if I missed any existing >> options for this type of configuration, let me know! >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elixir-lang-co...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/a956613f-7ef1-435c-8aaf-ab3af8058d5dn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/a956613f-7ef1-435c-8aaf-ab3af8058d5dn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/0d9d8a78-fd31-4b7d-8c6d-6f7741027493n%40googlegroups.com.