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.
