It would be a little bit hacky and I do not know if it would be good place for it, but you could “overuse” @moduledoc attribute with attributes (is it proper nomenclature?):
defmodule MyBoundary do
@moduledoc exports: [
# …
]
end
hauleth
4
sasajuric
Author of Elixir In Action
Folks,
I want to thank you all for providing the encouraging feedback and some great food for thought. Owing to your comments, I’m even more convinced that we can build a solid boundary enforcement tool for Elixir.
As a result of your comments, and the issues reported on the repo, I now realize that some of my original ideas were not on the right track. That’s actually a good thing! While I was a bit reluctant about sharing my work at such an early stage, I’m now happy that your review helped me discover some foundational problems so early on in the process.
So at this point, I’m increasingly leaning towards the following changes:
- allowing partial coverage (not all modules have to be a part of some boundary)
- switching to a decentralized solution
- prioritizing nested boundaries (boundaries within boundaries)
I plan on writing a detailed proposal, but I probably won’t make it this week, so I just wanted to let you know that I’m intensively thinking about this.
25
sb8244
Author of Real-Time Phoenix
This looks awesome!
To the tune of how boundaries can be awesome, we had a JavaScript project which was 1 codebase split across background and foreground pages (chrome extension). Implementing a boundary type system ensured that we never put background-only concepts in the foreground (where they would break). I caught several errors that I added in once this boundary checker was implemented.
Having a similar type of concept for organizing Elixir code would be really useful. I’m convinced that “people policies” are not enough, only tools can guarantee it. The compiler seems like the right place for it.
4
sasajuric
Author of Elixir In Action
sasajuric
Author of Elixir In Action
The first draft of all proposed changes is now implemented in this PR. Note that some parts (most notably ignoring checks) are implemented in a somewhat different way. The relevant links are included in the PR description. I’ll leave the PR sit for awhile in hope of getting some feedback.
4
sasajuric
Author of Elixir In Action
sasajuric
Author of Elixir In Action
Now that Elixir 1.10 is released, I pushed the changed internals which rely on new compilation tracers. The new version requires Elixir 1.10, and the usage is slightly changed. See changelog and docs for details. I also decided to push the package to hex. The new version is 0.2.0. Those who are using the library but aren’t on Elixir 1.10 yet can use 0.1.0.
13
sasajuric
Author of Elixir In Action
Started working on the support for managing external dependencies. The idea is that you can do something like this:
defmodule MySystemWeb do
use Boundary, externals: [ecto: [Ecto.Changeset]]
end
to restrain ecto modules only to Ecto.Changeset (and Ecto.Changeset.* if such exist). Other external deps are unrestrained.
Demo:
The code is pushed to GH master, but not yet published on hex, since I’d like to get feedback on the interface. Docs for the new feature are available here.
8
LostKobrakai
I’m wondering a bit about the mixture of blacklists/whitelists. The keys of the :externals list form a blacklist, while the values are a whitelist of allowed modules per application. I would find for example use Boundary, externals: [ecto: [except: [Ecto.Changeset]]] to be clearer.
1