This is a absolutely great point to address too, even though this falls into the extremely complex domain of types. For first releases I would be happy even with a few improvements over ecto.
D4no0
libo
https://github.com/LiboShen/elixact/issues/1
Since it seem more complex than everybody thought initially, I made this issue to track the discussion in GitHub. Feel free to add comments.
0
mudasobwa
Creator of Cure
Well, I meant stuff like Supervisor.child_spec/0 which is “core” by all means. To support it, one should compile everything with docs chunks, load all these chunks, store them somewhere…
I went through this road till the end in tyyppi, and once I did, I immediately and inevitably abandoned the library. Even despite validations (including but not limited to unions) worked in a runtime (see this test.)
Matchers are proved to work and might be borrowed from there as is.
0
Eiji
Oh, for sure that’s a Remote type in Elixir core. 
For initial support I wanted to suggest Basic types | Typespecs reference @ Elixir documentation with few remote types like ModuleName.t() in core modules (Range, String), but without stuff like Supervisor.child_spec/0.
Well … there is no need to store them, right? I take a look what iex helpers are doing and they simply call Code.fetch_docs/1 and deal with nested structures. It would not be few lines of code, but rather a small module so supporting it doesn’t look very hard.
However I agree that every project should not do that. I believe we need a hex package to:
-
Fetch result typespec for functions, so we would be able to
@spec func_name(…) :: unquote(same_as(Mod.fun/arity)). -
Function to “flatten” typespec which would fetch
RemotesandUser-definedtypes and translate them into a same nested structure, but using onlyBasic,LiteralsandBuilt intypes, so it would be easier to parse them.
Did I miss something else?
0
mudasobwa
Creator of Cure
In :prod we don’t have docs chunks, they are stripped out. That’s why I said “To support it, one should compile everything with docs chunks, load all these chunks, store them somewhere…”
1
Eiji
I see, so it’s only about prod runtime as docs could also be stripped when compiling code? Hmm … 
So … we would need to fetch docs and if it fails load it from cache … That cache would need to be added to priv directory, let’s call it priv//cache for now … That’s really a problem … Even if we cache results we may not have them when compiling code to prod, so even cache may be a bad idea … The only way would be to fetch sources and get docs from there, but it’s too tricky … 
Yeah, there is no good way to deal with it. Will remember it, thanks. 
0
gtcode
Been grinding on a fork of Elixact for the past week, as it’s a foundational dependency for the DSPy Elixir port in progress:
https://github.com/nshkrdotcom/elixact
The features are 99% on parity with Pydantic for the subset needed for a DSPy-style buildout.
Will be happy either way, whether the original project owner merges these significant changes or not. Will create a new project if the merges are declined.
edit: While the code is very stable, there are a few smells that came up. First was a somewhat disorganized layering with regard to so-called ‘enhanced’ functionality when I got to the runtime schemas. Further, some of the test or example names are poor, such as ‘phase 4 tests’ that were relevant at the time. The facade itself, however, should be fairly clean.
1
libo
Hey gtcode, thank you for working on the improvements.
Could you give me a list of what features you were adding, and ideally break your changes into small but self-contained chunks that can be meaningfully reviewed?
I saw your PRs yesterday and it will take me some time to review (bcs they are huge: 15000+ lines of new code in total 
)
1
gtcode
hey Libo,
Did some review on the fork. It wound up being really clunky! So I cancelled the PR for now, since it is unclear if a frankenstein that can handle compile time and run time schemas per the “enhanced” arch is good/performant/useful.
I wound up making a new, minimal proj tailored for my needs:
https://github.com/nshkrdotcom/sinter
Thanks to your project, Libo, I was able to iterate and settle on the simplified Sinter arch as a result of the fork.
As for the Elixact mods, which are extensive, plz review to see if it makes sense.. It should be backwards compatible with your arch. I am just not stoked on my “enhanced” arch which evolved a bit organically and tried to do too much!
That’s why I cancelled the PR.
Having said that if you’d like to proceed, can you eval nshkrdotcom/elixact and provide feedback on revisions? I’ll work on refactoring per your direction (since the proj ultimately is your vision) before submitting a better PR. It may be worth considering whether to refactor/downsize/focus my fork.
2
gtcode
@libo The changes were so huge, it really isn’t the same lib anymore. I wound up just creating a new project.
The README.md includes a credit indicating that it was based on your work. Thank you.
1