Let’s separate the repository naming convention (whether -f or .f) and how the package is actually being used. Let’s also not worry about any potential current limitations of fpm.
Let’s start with how the package is actually being used.
Let’s look at Julia. In there, the packages are names such as Polynomials.jl (Manual · Polynomials.jl) and then used as:
Pkg.add("Polynomials")
In other words, inside the Julia environment, you do not append .jl, you just use Polynomials.
Now let’s look at fpm.toml of the fpm package:
[dependencies]
[dependencies.toml-f]
git = "https://github.com/toml-f/toml-f"
rev = "2f5eaba864ff630ba0c3791126a3f811b6e437f3"
Currently this is a temporary solution, since we do not yet have a package registry. So let’s look at Cargo to get an idea how this will look in the future, say, Cargo.toml of the bat package:
[dependencies]
atty = { version = "0.2.14", optional = true }
ansi_term = "^0.12.1"
ansi_colours = "^1.0"
console = "0.14.1"
...
As you can see, there is no .rs or -rs appended. So in the future, the fpm.toml will look like:
[dependencies]
toml-f = "0.14.1"
And I do not like appending -f there, which would be eventually for all packages.
I know @everythingfunctional mentioned that there is already a precedent, but this is actually not a good precedent.
This should look like just as this:
[dependencies]
toml = "0.14.1"
The same with symengine, it should just look like:
[dependencies]
symengine = "0.7.0"
and it just means the Fortran version of symengine, since we are in Fortran, so you can’t use any other version, for example it cannot be the Julia version of symengine (symengine.jl). The default for us is Fortran, so we should not use any of the following:
[dependencies]
symengine.f = "0.7.0"
symengine-f = "0.7.0"
symengine-fortran = "0.7.0"
However, there is one issue to resolve. How do we write fpm.toml for the symengine.f package itself? In there, it needs to depend on the C++ version of symengine. There are two ways forward:
-
Either we simply build the C++ package as part of symengine.f (by supplying a build script that fpm will support in the future). In that case, the Fortran package can and should just be called symengine, as there is no other package
-
Or we first create a symengine.cpp package, which contains the original C++ version (no wrappers). Then in symengine.f we depend on the symengine.cpp package.
If the second point is used, there can be some confusion. For example, if the Fortran package is just symengine, does it refer to symengine.f or symengine.cpp? Given that we are in Fortran, it would seem natural that if there are no -f or .f, it refers to the Fortran version, and we use extension like .cpp if the package does not contain wrappers and is just written in another language (to be used as a dependency). Note that symengine.cpp is just this GitHub url: https://github.com/symengine/symengine, it does not have a .cpp suffix (to further confuse things).
For pure Fortran original upstream code, say stdlib or fpm, I don’t think we need to append anything, we can just use stdlib. We can append stdlib.cpp for C++ wrappers to our Fortran stdlib.
So one way forward is to not use any suffix for upstream packages written in Fortran, and perhaps use a suffix just for wrappers, to make it clear that those are just wrappers. That leaves room to use no suffix for the original (C++) package. So symengine would mean the C++ package and symengine.f the Fortran wrappers. So toml-f should be renamed to just toml, because it is not a wrapper but an original package. The problem is that the module names cannot have .f or -f in them, breaking the current fpm convention for Fortran module names starting with the package name.
Note that I am talking about how the package is referred to in fpm.toml as well as how the modules are named, as fpm enforces to put the name of the package in the module name. (Further complicating the matter, since we can use neither -f or .f in the module name.)
Given all this, the cleanest so far to me seems:
- in
fpm.toml we use no suffix, and the Fortran module names start exactly with the package name. That restricts available characters in the package name to characters and underscore. So toml and symengine, and the Fortran module names start with toml_something and symengine_something, enforced by fpm.
- If we need to build the original C++ package as an
fpm package, we name it symengine.cpp in fpm (@awvwgk mentioned you can’t use . in toml, so perhaps symengine-cpp). That way it is clear which one it is. Then the Fortran symengine wrappers can simply depend on symengine.cpp in their fpm.toml.
Let’s first figure out whether we should use -f suffix or no suffix in fpm.toml. I vote for no suffix. Then we can go from there to design the rest.
