josevalim
The goal of private modules is to define a module that cannot be trivially accessed by other modules where they are not visible to.
In this proposal, private modules work by declaring exactly which other module prefixes can access it:
defmodulep MyApp.Private, visible_to: [MyApp] do
def hello do
IO.puts "hello world"
end
end
In the definition above, only MyApp and modules nested under it can access MyApp.Private. In this other example:
defmodulep MyApp.Nested.Schema, visible_to: [MyApp.Nested] do
def hello do
IO.puts "hello world"
end
end
only modules in MyApp.Nested and under it can access MyApp.Nested.Schema.
To access a private module, you must explicitly require and alias it:
defmodule MyApp.Other do
require MyApp.Private, as: Private
Private.hello
end
The require is necessary to validate the visibility rules. The alias is required to give the private module a proper name (as we will learn later on, private modules live in different namespaces).
Private modules can be arbitrarily nested too:
defmodulep MyApp.Private, visible_to: [MyApp] do
defmodulep Nested, visible_to: [MyApp] do
def hello do
IO.puts "hello world"
end
end
end
Requiring MyApp.Private does not automatically require MyApp.Private.Nested. It still need to be explicitly required either directly:
require MyApp.Private.Nested, as: Nested
If you have already required Private, you can also require Nested from the Private alias:
require MyApp.Private, as: Private
require Private.Nested, as: Nested
Nesting
defmodulep works as defmodule as it can be accessed directly following its definition:
defmodule Foo do
defmodulep Bar, visible_to: [MyApp] do
...
end
Bar # We can access bar here even if not in visible_to
end
In other words, a more correct description of defmodulep is that it is visible to any following module declared in the same file or to any module declared in visible_to. In fact, :visible_to may be skipped for nested private modules which means they are only accessible to the following modules in the same file.
Testing
In order to test a private module, you need to make sure the private module is visible to the test module. Since most private modules are visible to their own rootname, testing just works if you follow Elixir’s testing conventions. For instance, a private module MyApp.Foo.Bar is likely visible to MyApp or MyApp.Foo, which means the default test module, which is MyApp.Foo.BarTest, should have access to the private module. In other words, the following code should work just fine:
# lib/my_app/foo/bar.ex
defmodulep MyApp.Foo.Bar, visible_to: MyApp.Foo do
...
end
# test/my_app/foo/bar_test.exs
defmodule MyApp.Foo.BarTest do
use ExUnit.Case
require MyApp.Foo.Bar, as: Bar
...
end
Inspecting private modules
Private modules work by being assigned a different naming structure. If you define a private module Foo.Bar, it will actually be compiled as :"modulep_DDD_Elixir.Foo.Bar", where DDD will be a arbitrarily assigned number, instead of the usual Elixir.Foo.Bar. The number is arbitrary to discourage developers from accessing the underlying module directly, as this number may change at any time. The only way to safely access a private module is by requiring and aliasing it first.
Proof of Concept
I have written a proof of concept that is “ready to use today”™ for those willing to try this idea out:
https://github.com/josevalim/defmodulep
However, the proof of concept has certain limitations:
-
Since we can’t change the behaviour of
require, the library introduces arequirepto require private modules. -
If you define
defmodulep Fooand thendefmodule Foo, the proof of concept won’t warn. -
If you invoke
SomePrivateModule.foowithout requiring it, the error message says the module does not exist, without giving any hints the module is actually private (this may or may not be a feature). -
Private modules appear literally as
:"modulep_DDD_Elixir.Foo.Bar"but it could show up asFoo.Barwhen inspected by updating theInspectimplementation for atoms -
If you define a module
defmodule Publicnested insidedefmodulep Private,Publiccannot be accessed directly but only viarequirep Private, as: Privateand then by callingPrivate.Public. This will be fixed if we add this to Elixir by makingModule.concat/1to be aware ofmodulep_DDD_prefixes.
All of those limitations could be addressed by adding defmodulep
to Elixir.
Your turn
I would love to hear feedback on:
-
The feature
-
Implementation details and concerns on this area
-
The proof of concept
Also, I would love examples of how other languages tackle private modules. A common implementation is to have the visibility of your modules associated to the “idea of a package” but Elixir does not quite have the concept of a package. Elixir does provide the idea of “applications” but they are define only after the code is compiled. That’s why the “package” approach has been ruled out in favor of a explicit visible_to control.
Where Next?
Trending in News
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Bringing learning, work and compliance together since 1987.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #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.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
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 21 to 12- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
josevalim
Here is the new discussion: Proposal: Private modules (general discussion)
josevalim
Thanks everyone! I will close and lock this one for now and start a new thread that attacks the problem more generally and less with a specific implementation.
scarfacedeb
I agree with @JEG2 sentiment too.
Some kind of warning will help to define the public interface and its borders. But making it too strict does more harm than good.
I can think of at least 2 uses of open private modules:
As @JEG2 said, sometimes you have to use private modules in IEx in prod.
You may encounter an unexpected error that you didn’t anticipate in your code and the quickest way to debug it is to call internal modules by hand and check the results.
You could also use tracing in these cases, but I don’t see why we can’t have both.
When I’m learning how a new library (or app) works, I often call its internal modules directly to experiment and get a better idea how they work under the hood. Now it’s easy to do in iex and it doesn’t require to now about any new concepts (such as private modules, their visibility, etc).
I think that a warning is the best of both worlds.
It’ll inform the unaware users that they shouldn’t use the module directly, but allow to debug it in the critical circumstances.
josevalim
The problem with this line of thought is that it gives an impression of instability since packages break whenever there is a new release of something they were using a private API of. It also discourages communication in favor of quick work arounds. Well, if you need private functionality, why not start a discussion on the best way to expose it?
My experience coming from the Ruby community which (at the time) did not value contracts and visibility that much is that this leads to a lot of pain down the road, especially as systems grow in complexity. Updating only a small part of the system becomes impossible, because a minimal change breaks many unwarranted things along the way. It usually goes like this: let’s update Elixir! Unfortunately, updating Elixir breaks package X because X used a private API. So we have to update package X too but wait! That breaks Y and Z. And so on and so on.
Also beware of “truths made along the way”. It is very likely a community ends-up accepting that “being able to call privates is a good thing” because this behaviour was there since the beginning and it is impossible to change it now, so the best they can do now is to focus on the pros despite the cons. Note this is not a criticism to Python nor I am implying it is the case here, as I am not that familiar with the Python community, but it is an effect we see in all communities, including Elixir’s.
arkgil
I’m all for this feature, for the reasons mentioned by @mkaszubowski and @dimitarvp. It clearly demonstrates the intent of the author and helps to maintain discipline in larger codebases.
sztosz
I’m all against hard failures. Just look at Python, encapsulation is done by simple convention and name mangling. Quick search gave me this nice article explaining how things are done Redirecting to: /posts/private-protected-and-public-in-python/ People who use private API’s are to blame themselves. If they were not aware that given API was private, then we can improve this, sure, make information more clear that something is not to be used outside of given app, mix project, whatever. But if someone has a strong need to use private API for whatever reasons, then he will do it anyway, but will have to write hacks for accessing private modules. Beside even as an author of given library, if I allow people to use it… who am I to say this part you but that one you can’t?
josevalim
@LostKobrakai the require+alias are necessary if we want hard failures. If we want a warning, then it would be on a best effort fashion and it would be quite trivial to bypass it. For example, if we move it to a warning, I could bypass any visibility check like this:
LostKobrakai
I really like the intention, but also don’t really favor the require call. Would be nice if only the private module would need to say to whom it’s available and any module using it wouldn’t need to care (or just have some generic
use Private). Needing to keep track of the relationship from both sides seems like a lot of boilerplate. Like e.g. a phoenix context might easily gather up quite a lot of private modules to access. On the other hand I also like the explicitness. It’s probably worth some exploration anyways.I’d also add my vote for a way to have it just warn and not fail compilation. My ideal would be failing by default, but allowing compilation with warnings via a cli flag. This way we don’t hinder discoverability. If I want to check out how some private code works I can try out any implementation I aspire and be much more focused in making an effort of making parts or the whole functionality public with any maintainers involved. Also it’s local to your own project this way and wouldn’t compile e.g. as a hex package (besides maybe telling people to also use the flag, which is like a big flag of doing something not the supposed way).
dimitarvp
I tend to agree with that one. I think the alias part should be optional – unless the feature couldn’t work without it?
dimitarvp
I am very much in favor of this proposal, for these reasons:
Clear communication of intent. As mentioned several times, most languages we the community here are familiar with have a mechanism to bypass a private module / function boundary. It’s not the point to have a perfectly private code pieces. The point is to discourage people when trying to use parts of your library which are supposed to be implementation details. Are there people dedicated enough to cross the boundaries? Of course. But, by doing that they make a conscious decision to rely on internal and brittle APIs and they are likely locking themselves to one version of your library. I would bet that most devs wouldn’t do it when faced with a compiler error – even if they can bypass it. People just want to get their work done and move on. They won’t reverse-engineer your library unless you leave them no other choice.
Maturity of the language and the ecosystem. Reading through HN and Reddit regularly, I get the impression that many still view Elixir as a toy language – and having the ability to poke in the guts of any of your dependencies at runtime is one of the reasons why they think so. IMO having decent private module/function mechanism – as this proposal is – sends the message that this community and its tech are ready for even more serious work. (Personally, I was convinced the moment I found OTP but many others need more convincing.)
It helps with the single-responsibility principle programming. Example: it has been pointed out many times in this forum that when an app grows enough, it’s a bad practice to directly use the Ecto schema modules. At certain point your DB design trails behind your domain schemata and requirements and it’s IMO much better for only the domain modules (e.g. Phoenix contexts) to have access to the schema modules.
It can help facilitate understanding of the app/library. Given this code:
…trying to use
Internalanywhere else but its intended namespace can give you a compile-time error like this:This can help people guide newcomers to the proper place to use their library (or even a singular module inside a company project).
In favor.