Not necessarily. It may also look like:
{ :extensions_live_view_multi_render “~> 1.0.0”}
or indeed
{ :extensions_lv_multi_render “~> 1.0.0”}
Right?
DaAnalyst
egze
I was under the impression that the package name is also how your root module is called. Maybe not enforced, but it’s the typical case.
So the package name :extensions_lv_multi_render means that the root module is ExtensionsLvMultiRender and that’s cool. But to have the main module called Extensions is different.
0
DaAnalyst
Why would I need a package root name module?
What is wrong with just having one module in the library named Extensions.LiveView.MultiRender while expecting to add more Extensions.mn.xy in the future without ever having the root module Extensions.ex?
I am asking sincerely.
0
egze
I mean a root namespace, didn’t mean that there needs to be a real file for it.
My point still stands though, that I expect the package from hex to have the root name space exactly like the package is called. So if the top namespace for the module Extensions.LiveView.MultiRender is Extensions, I would expect the hex package to be called :extensions which I find too generic and confusing.
In the end - it’s your choice. You made the library and it’s awesome! I will use it even if it’s called :extensions 
But please sleep on the naming again if you can 
0
DaAnalyst
I like your last comment. But I still don’t get your point and am beginning to doubt my own understanding of the naming conventions in Elixir.
Why do you think I can’t make the library to look like this:
full module name:
Extensions.LiveView.MultiRender
directory tree:
- extensions_live_view_multi_render
- lib
- multi_render.ex
deps:
{ :extensions_live_view_multi_render "~> 1.0.0.}
0
egze
I think nothing prevents you technically. But this is not the naming I’d expect from a library. All libraries I’ve seen have the same package name and the root module name.
0
DaAnalyst
Ok. But those libraries are not extensions of a very particular functionality at a very particular hierarchical level of another library, right?
What I am trying to say is that by the time I make the very next extension (which btw, unless the authors of LiveView come up with the helpers for lists in containers fast, is going to be soon), this next extension library will look like
extensions_live_view_distiller
So it will make sense to have them in your dependency folder listed like this:
..
decimal
ecto
ecto_sql
extensions_live_view_distiller
extensions_live_view_multi_render
file_system
floki
..
0
DaAnalyst
After a serious consideration (the proverbial sleeping over it) and reading the instructions on naming on hex.pm, I decided to follow the way that is somewhere in between what Jose suggests and what I feel like is right thing to do.
The module name will be: PhoenixLiveViewExt.MultiRender
and the library name will: lv_multi_render
That way I respect the convention and ownership of the Phoenix.LiveView, the library name stays short, it is clear that it’s about LiveView to whomever uses it and I don’t end up with a long module base name which I really want to avoid.
Didn’t think this would be such a mind job.
0
egze
Awesome! Just curious what’s keeping you from naming the package phoenix_live_view_ext? Because you want to publish your other ideas as separate libraries?
Hex.pm says:
- If you are providing functionality on top of an existing package, consider using that package name as a prefix. For example, if you want to add authentication to Plug, consider calling your package
plug_auth(orplug_somename) instead ofauth(orsomename).
You could then just add more modules to the library and users will take only parts that they need.
Regardless, I’m looking forward to the first version!
1