Isn’t this restriction too demanding on already existing, long lived packages?
-
Changing module names breaks the API, for a new or rising project this is not a problem, of course, but otherwise, especially if used in a fair amount of code, this is a non starter for a library.
-
Even if a library would accept to break the API for the benefit of entering the register, the new API would need to be better or at least equivalent. Prefixing with the name of the library could easily get too verbose and clumsy. Or conversely requiring the name of the library to be just a few characters would be a serious restriction, in many cases (and again, long lived projects would not want to change name).
I see where the issue comes from and agree that module aliasing would be nasty to deal with. Probably it’s another supporting point for wanting nested modules in the language itself (so a library would just export one top level module to the public library, and the others would remain accessible through nested qualification). But that is far in the future so we cannot rely on it for now.
I suppose you might want to mangle module names internally within fpm. As far as the current state of the toml file goes, the user would be required to explicitly resolve the clash there, when declaring the external modules. Something like
external-modules = ["stdlib/sorting", "alternative_lib/sorting"]
or
external-modules = ["sorting@stdlib", "sorting@alternative_lib"]
Whatever is easier to parse. Then the difficult part would be that in the source you have just use sorting and fpm would need to disambiguate by intersecting the info provided in the toml with… probably filesystem information. The build tree is already well organized in that sense, each dependency has its own subtree and I believe fpm should be able to provide the compiler with different include paths, for different source files (I know it cannot right know). Some residual limitation would be that you could not use the two clashing modules in the same source file but well, that’s a language level problem that fpm cannot solve by itself.
It’s not too much related, but since we are discussing this: maybe requiring the author of a fpm package to make an account on the centralized registry website (reasonable imho, even comfortable for advertising own libraries…) would allow to even manage in a similar way clashing package names.
Like
[dependencies]
fortran-lang/stdlib={...}
someone-else/stdlib={...}
Thus solving two major problems (racing for name reservation could easily become one) with a somewhat unified logic, at least from the user perspective.
). This is the core of the issue in tightly binding module names and official fpm project names: you want the first to be reasonably short in your code, you need the second to be original, distinguished and inevitably longer, to avoid “overbookings” in the registry. I don’t know how to solve.
).