Incorporating more ExUnit / Elixir APIs

Hello, I’m trying to gather some feedback for the community to (possibly) construct a proposal if appropriate.

Background: I was working on upgrading ESpec to be compatible with Elixir 1.10. I ran into the following issue described over in this github issue. The main issue was that the “stale” feature was using Kernel.LexicalTracker module private API which was changed with the release of Elixir 1.10 and ESpec.Diff was using the ExUnit.Diff private API which changed with the release of 1.10.

I was thinking now that we’ve run into this issue in the wild in the ESpec library, it might be worth discussing how to incorporate more public APIs from Elixir/ExUnit (rather than private APIs, which is frowned upon for good reasons). It’s something I thought about when doing the “stale” feature but couldn’t really find a good way to go about it at the time.

The question I’m soliciting feedback on:

  1. Is there an obvious reason why APIs which ExUnit references (e.g., Kernel.LexicalTracker, ExUnit.Diff) should not be made public?
  2. Any other thoughts/concerns/feedback?

Related resources:

PS - following this thread as the directions for soliciting suggestions - How to use the Suggestions & Proposals section

Hi @treble37, I don’t know much about these APIs, but just dropping my $0.02:

ex_unit ships with Elixir, seems reasonable to me that as core code that it is, it depends on inner core code, still not stable enough to become a public contract, so true that it just changed.

I’d not enjoy much if Elixir would be now at version number 80.0.3987.106, just because some compiler operational stuff needed to change from time to time :smile:

However, libraries sometimes just need to depend on these to work right, but this need/choice will come with a higher maintenance cost. When you depend on a non-public API, it’s interesting to watch out for release candidates, having a CI build on the edge might also help, so you can join the change conversation while it’s happening.

But yes, I didn’t help you much with the specific ExUnit / LexicalTracker stuff, other people more qualified in the matter will come for help hehe, hope this gets sorted out :+1:

PS: I don’t know what is the current state of private modules proposal, it seems it could address this problem, perhaps in a more strict way.

1 Like

Thank you @rodrigues for the kind reply. I knew the dangers of rolling with a non-public API, so I guess I get to be responsible for my poor life choices :smiley: :sweat_smile: I’m pretty close to working around this…so hopefully soon.

1 Like

Making an API public is a much bigger effort than simply keeping them private. It is like writing an article, while they are private, they are in draft state where we can frequently improve it and move things around until we find the optimal structure. The diffing algorithm is a perfect example, as it was fully rewritten on Elixir v1.10 to also work with patterns. Also, once we make it public, we have to maintain it forever.

However, one of the reasons why we haven’t made them public is because nobody asked for them - and once this process starts, we need to have a proper discussion about how to achieve the desired outcome. For example, mix espec is mostly a direct copy of mix test, so while you see the lexical tracker erroring on recent Elixir versions, I would say it is a symptom of a problem that could perhaps be tackled at a much higher level.

5 Likes