nathanl
From the docs on import:
Note that
importis lexically scoped too. This means that we can import specific macros or functions inside function definitions:
defmodule Math do
def some_function do
import List, only: [duplicate: 2]
duplicate(:ok, 10)
end
end
In the example above, the imported
List.duplicate/2is only visible within that specific function.duplicate/2won’t be available in any other function in that module (or any other module for that matter).
The example given is silly; it’s shorter and clearer to call List.duplicate(:ok, 10). But you have to import Ecto.Query to use its macros. I’ve used a function-local import when only one function in a module needs import Ecto.Query, but it’s been flagged in code review.
When, if ever, would you use import this way?
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Phoenix, LiveView, multimedia pipelines, distributed systems. 400 engineers, Elixir since 2017. Available for hire.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #ai
- #elixirconf-us
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
lud
Sometimes in a test helper in a test file I import
Ecto.Querybecause that function is the only place where we will interact with the DB.dimitarvp
I absolutely would and have used
import Ecto.Queryinside a single function, a good amount of times. Trouble is that many don’t like it for reasons they can’t explain very well themselves and deny a PR approval until theimportis extracted top-side.I partially get their point: if you get to a point where tracking the source of an imported function becomes difficult then that obviously means you should break your module apart on several smaller ones. I am a huge fan of such incremental refactorings.
But IMO some of the
import-s (when not using:only) can bring in quite a lot of context that might be surprising or lead to weird compile-time warnings and runtime errors if f.ex. you import two modules and they have overlapping function names. For those cases either use:onlyreligiously or, like you are demonstrating here – just limit the scope of theimport.It’s a very valid technique IMO. Though nowadays I lean to using
:onlyor reducing the sizes of modules / functions more than reaching for lexically scopedimport.LostKobrakai
There’s also more more parts to lexical scopes than just function definitions. E.g. you could do an import outside of a module definition and it would affect the whole file, you could have an import within an anonymous function and it would only apply to that function, …
Personally like people before I’d also argue having a single function do an import can be perfectly fine.
sodapopcan
Consider as well libraries that (judiciously) override kernel functions, for example: Image’s
Mathmodule.I’m all for importing inside functions in scenarios like you describe and even importing just above the function where it is first used. Any push back is very much a “this is the way we’ve always done it” scenario (angry monkeys!). It makes no sense to me that you would want to spread these things apart. Same goes for mandating that module attributes must be at the top and that private functions must be at the bottom.
I never considered this and could have come in handy in some code I no longer work in