Mix.install is a perfect new feature. I am already using that to perform some scripting on my servers. I would like to split my logic into modules and put each module in its own file. Is using Code.require_file in the main script the right approach to use? Thanks. 
stefanluptak
2
josevalim
Creator of Elixir
If you want to start adding some structure, then you most likely want to build a project then and rely on an escript. We are most likely not going to be supporting complex structures via scriptings. In any case, Code.require_file should work.
4
stefanluptak
Thanks a lot for your reply, José. That makes sense. I meant like 2 or 3 files and I guess a project would be overkill for that. I will take a look at the escript anyway.
0
massimo
dig is already present in Elixir, it’s called get_in
iex(12)> get_in(pets, [:dogs])
[
%{favorite_toy: "rope", name: "Scrump"},
%{favorite_toy: "ball", name: "Stitch"}
]
iex(13)> get_in(pets, [:cats, Access.at(1)])
%{favorite_toy: "laser pointer", name: "Janice"}
iex(14)> get_in(pets, [:hyenas, Access.at(0), "what is this"])
"oh no"
iex(15)> get_in(pets, [:dogs, Access.at(0), :favorite_food, :ingredients])
nil
it also support custom lookup functions
from the documentation
iex> users = [%{name: "john", age: 27}, %{name: "meg", age: 23}]
iex> all = fn :get, data, next -> Enum.map(data, next) end
iex> get_in(users, [all, :age])
[27, 23]
in this case the all function could be replaced by the built in accessor helper function Access.all
2
thepeoplesbourgeois
It breaks at the tuple border
iex> nested = [{:hi, [ho: %{hey: {"there", "how ya doin'?"}}]}]
[hi: [ho: %{hey: {"there", "how ya doin'?"}}]]
iex> get_in(nested, [:hi, :ho, :hey, Access.at(1)])
** (RuntimeError) Access.at/1 expected a list, got: {"there", "how ya doin'?"}
0
massimo
Yes, because Access.at is defined only for lists, see elixir/lib/elixir/lib/access.ex at v1.11.4 · elixir-lang/elixir · GitHub
But you can defined a custom function that handles tuples.
0
thepeoplesbourgeois
True. I imagine that a similar custom tuple handler would have to be written by every project that may want to utilize Access on tuples, and I know (from having crashed my Phoenix enthusiasm train on this error multiple times with Guardian, Ueberauth, and Joken) that any project that wanted to utilize Access on any given struct would have to write one or two defimpls in order to do so. Once I find the time to put passive_support up on Hex, dig will just work, on tuples, structs, lists, keyword lists, and maps.
And now it can operate on entire lists like Access.all does for get_in
0
josevalim
Creator of Elixir
slouchpie
I am not happy with the docstring for Kernel.then. It reads:
@doc """
Pipes `value` into the given `fun`.
In other words, it invokes `fun` with `value` as argument.
This is most commonly used in pipelines, allowing you
to pipe a value to a function outside of its first argument.
### Examples
iex> 1 |> then(fn x -> x * 2 end)
2
"""
which is all correct but why is the given example a case where we are piping a value to a function as its first argument?
I would prefer an example like this:
### Examples
iex> 1 |> then(fn x -> Enum.drop([1, 2, 3], x) end)
[2, 3]
I made the smallest PR of all time: Provide a more fitting example of Kernel.then by peaceful-james · Pull Request #10956 · elixir-lang/elixir · GitHub
Just to to get my name in the git log hahahaha (joke)
2
Sanjibukai
Hi..
Just out of curiosity, what kind of scripting do you need on your server? Is it for doing some kind of DevOps tasks?
Also, I wonder why I never heard of escripts!?
1