# Kick-off for fpm leadership team
**URL:** https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720
**Category:** Uncategorized
**Created:** [November 11, 2022, 7:03pm UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720 "2022-11-11T19:03:56Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@awvwgk](https://fortran-lang.discourse.group/u/awvwgk)
#### Post date: [November 11, 2022, 7:03pm UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/1 "2022-11-11T19:03:56Z")
With the NumFOCUS application of Fortran-lang and the STF project on the package registry, it is time to get more concrete with the long-term goals for the development of fpm.
Therefore, we want to create a working group to design the roadmap for fpm. If anyone is interested in joining a kick-off meeting, please let us know here. Note that this requires a more long-term commitment, of at least the next six months while the STF project is running, preferably beyond.
---
### Author:  [@gnikit](https://fortran-lang.discourse.group/u/gnikit)
#### Post date: [November 11, 2022, 7:17pm UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/2 "2022-11-11T19:17:43Z")
Sounds great count me in!
---
### Author:  [@milancurcic](https://fortran-lang.discourse.group/u/milancurcic)
#### Post date: [November 12, 2022, 1:11am UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/3 "2022-11-12T01:11:30Z")
I’m in.
---
### Author:  [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)
#### Post date: [November 12, 2022, 10:03am UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/4 "2022-11-12T10:03:11Z")
I’m also interested.
---
### Author:  [@certik](https://fortran-lang.discourse.group/u/certik)
#### Post date: [November 12, 2022, 10:59pm UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/5 "2022-11-12T22:59:21Z")
Perfect, thank you everybody. I am in too.
Let’s meet once a week over video initially, to resolve and make decisions about some big issues that we need, so that the STF projects can implement it.
Can you please fill out this doodle form:
[Doodle](https://doodle.com/meeting/participate/id/bYWqDP2e)
And let’s see if we can agree on a slot.
---
### Author:  [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)
#### Post date: [November 13, 2022, 2:36am UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/6 "2022-11-13T02:36:34Z")
I’d like to stay involved.
---
### Author:  [@certik](https://fortran-lang.discourse.group/u/certik)
#### Post date: [November 14, 2022, 9:24pm UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/7 "2022-11-14T21:24:39Z")
We’ll meet tomorrow on Tuesday at 11am Mountain time (10am Pacific, 1pm Eastern). I sent a calendar invite to everybody who has responded in the Doodle poll so far.
---
### Author:  [@awvwgk](https://fortran-lang.discourse.group/u/awvwgk)
#### Post date: [November 14, 2022, 9:26pm UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/8 "2022-11-14T21:26:58Z")
Do you have a meeting link or should I create one? Also, could you please post the time in UTC as well (otherwise I’ll be paranoid about messing up my timezone calculation).
---
### Author:  [@certik](https://fortran-lang.discourse.group/u/certik)
#### Post date: [November 15, 2022, 5:30pm UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/9 "2022-11-15T17:30:36Z")
I sent the link as part of the calendar invite. It starts in 30 minutes from now. I just also sent a private email to everybody with the link. Let me know if you got it.
---
### Author:  [@certik](https://fortran-lang.discourse.group/u/certik)
#### Post date: [November 15, 2022, 5:47pm UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/10 "2022-11-15T17:47:37Z")
Agenda from my side (please post post what you want to discuss as well):
- Pros and cons of central registry (why did Zig decide not to have it?)
- How will we host it, and choosing a person or team responsible for keeping the server up
- Use namespace + project (like github) or just project (like PyPi and Cargo)?
- Enforcing prefix module naming convention at the fpm level and registry level
- Mechanics how we will make decisions (in a timely manner), how will will design things, and hearing from past experience where we failed to do so and how to fix it.
I am hoping to keep the meeting 40 minutes long.
---
### Author:  [@certik](https://fortran-lang.discourse.group/u/certik)
#### Post date: [November 15, 2022, 6:47pm UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/11 "2022-11-15T18:47:05Z")
My summary (please correct me below if I misrepresented something):
- Pros of a central registry:
- robust distribution, compared to a user removing a package, say, from github
- possibly faster download
- you can mirror it
- we control it
- Cons: somebody has to maintain, and paying for server costs, overhead of resolving disputes (if any), etc.
- Overall it seems we agreed we want a registry
- We will work on finding a person/team to maintain it and have to figure out hosting
- We should use a namespace + project, like github (it prevents the name squatting issue, a user/organization reserves a namespace on a first serve first come basis, but one can always choose a good looking name, just like you can still do that on github; then you can use any name you want for the project, and nobody else can access the namespace, unless you give permissions)
- prefix: we should enforce prefixes by default; and provide a command line option to opt-out;
- later we can discuss how to design a language feature such as namespaces for modules and implement in compilers + get it approved by the committee
- We will meet weekly for now, and we will try to find a person or a team to lead fpm, who will push to make decisions quicker; in case of big disagreements we will meet over video (like we did just now) with all interested parties and try to resolve the issue.
---
### Author:  [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)
#### Post date: [November 16, 2022, 8:02am UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/12 "2022-11-16T08:02:44Z")
A few notes I made:
- Local and central registries share the same architecture; this would allow having organizations (companies, institutes, …) or even an entire country to deploy it’s own registry behind a firewall.
- Existing method with git repositories should continue to work if possible. (Which namespace do such packages belong to? Does it matter?) If not possible, the sooner we break compatibility the better.
- Introducing a version field specifier for the fpm TOML manifest could allow for breaking changes.
- For namespaces we should evaluate design choices taken in Julia’s [Pkg.jl](https://pkgdocs.julialang.org/v1/), [PyPI](https://pypi.org/), [Spack](https://spack.readthedocs.io/en/latest/repositories.html), and [Cargo](https://doc.rust-lang.org/cargo/reference/registries.html)/[crates.io](https://crates.io/).
A few questions:
- Since fpm also has support for C and C++ projects, should those also be prefixed? This also extends to Fortran external sub-programs (i.e. standalone functions and subroutines)
- Will there be other requirements on packages, for example explicit default visibility in modules?
---
### Author:  [@gnikit](https://fortran-lang.discourse.group/u/gnikit)
#### Post date: [November 16, 2022, 11:23am UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/13 "2022-11-16T11:23:45Z")
> [@ivanpribec](#):
>
> For namespaces we should evaluate design choices taken in Julia’s [Pkg.jl](https://pkgdocs.julialang.org/v1/), [PyPI](https://pypi.org/), [Spack](https://spack.readthedocs.io/en/latest/repositories.html), and [Cargo](https://doc.rust-lang.org/cargo/reference/registries.html)/[crates.io](https://crates.io/).
Should we attempt to reach out to some of these teams and see if they have any advice for us/lessons learned?
> [@ivanpribec](#):
>
> Since fpm also has support for C and C++ projects, should those also be prefixed? This also extends to Fortran external sub-programs (i.e. standalone functions and subroutines)
I think we should. The prefix behaviour should be the same across C/C++/Fortran to minimise user error while writing fpm.toml files.
---
### Author:  [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)
#### Post date: [November 16, 2022, 3:25pm UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/14 "2022-11-16T15:25:10Z")
> [@gnikit](#):
>
> The prefix behaviour should be the same across C/C++/Fortran
What things in C and C++ should be prefixed? All functions, classes and structs? We actually have the same problem in Fortran with external procedures (e.g. that aren’t in a module). Should we also enforce that all Fortran projects have all procedures in modules? Is there a way in C/C++ to prevent name clashes?
---
### Author:  [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)
#### Post date: [November 16, 2022, 11:21pm UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/15 "2022-11-16T23:21:58Z")
> [@everythingfunctional](#):
>
> Should we also enforce that all Fortran projects have all procedures in modules?
Given that you can’t enforce it for C procedures, I’d be hesitant to require this for Fortran.
> [@everythingfunctional](#):
>
> Is there a way in C/C++ to prevent name clashes?
In C++ you have [namespaces](https://en.cppreference.com/w/cpp/language/namespace), e.g.
```cpp
namespace fpm {
// ...
}
```
In C things can go wrong in very subtle ways due to macros, function-like macros and `inline` functions. Say you offer an API with the following interface:
```auto
// process_api.h
void process(int N, double x[N]);
```
Now someone else might inadvertently use `N`, a capitalized identifier as a constant, e.g.
```auto
// definitions.h
#define N 42
```
Next, they write a main program:
```auto
#include "definitions.h"
#include "process_api.h" // boom!
int main(void) {
double x[4] = {1.,2.,3.,4.};
process(4,x);
return 0;
}
```
This will fail to compile as the substitution of `N` will invalidate the header. You can fix it by swapping the order the headers are imported in. But some day you might import a third header, or hit the via a transitive header.
You can also suffer clashes with the standard library; if you would pick `I` as a dummy variable in a header, all it takes to break the code is to [`#include `](https://pubs.opengroup.org/onlinepubs/009695399/basedefs/complex.h.html) which provides `I` as a macro for the imaginary unit. Not to mention the potential clashes with the name `process` itself.
What can you do to avoid the problem? In general you prefix all public and internal functions. For the dummy arguments in the public header you can either omit the variables names, use comments or prefixed identifiers:
```auto
void pp_process(int, double []); // omit
void pp_process(int /*n*/, double[] /*x*/); // inline comments
void pp_process(int pi_n, double pi_x[pi_n]); // prefixed (pp - public, pi - internal)
```
You can also face clashes with member names in `struct` and `union` types. Here’s a mixed C/C++ example:
```auto
// main.cpp
#include "ISO_Fortran_binding.h"
template
class FortranArray {
private:
CFI_CDESC_T(rank) desc;
};
int main(int argc, char const *argv[])
{
FortranArray<5> array;
/* code */
return 0;
}
```
The code look okays, but in fact there is a name clash between the template parameter, and a member of the unnamed C descriptor struct hidden underneath the `CFI_CDESC_T` macro.
```txt
$ g++ main.cpp
In file included from main.cpp:1:
main.cpp:6:2: error: declaration of ‘CFI_rank_t FortranArray::::rank’ shadows template parameter
6 | CFI_CDESC_T(rank) desc;
| ^ ~~~~~~~~~~
main.cpp:3:10: note: template parameter ‘rank’ declared here
3 | template
| ^~~
```
> [@everythingfunctional](#):
>
> What things in C and C++ should be prefixed?
For C++, namespaces should take care of most of the problems. But for a C header, to be on the safe side you need to prefix all identifiers: types (both `struct` or not), `struct` and `union` members, variables, enumerations, macros, functions, and function-like macros. You can take the `"ISO_Fortran_binding.h"` header as an example; everything is prefixed with `CFI_`.
For C, I imagine this could be difficult to enforce. Perhaps some large C projects have developed tools to maintain name hygiene. (cc @vmagnin, maybe you are familiar with how GTK handles this?)
---
### Author:  [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)
#### Post date: [November 17, 2022, 8:03am UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/16 "2022-11-17T08:03:58Z")
> [@ivanpribec](#):
>
> For C, I imagine this could be difficult to enforce. Perhaps some large C projects have developed tools to maintain name hygiene. (cc @vmagnin, maybe you are familiar with how GTK handles this?)
I don’t know if they have specific tools. I have found the GTK coding style document:
[https://gitlab.gnome.org/GNOME/gtk/-/blob/main/docs/CODING-STYLE.md](https://gitlab.gnome.org/GNOME/gtk/-/blob/main/docs/CODING-STYLE.md)
After a quick read, I have not found advice on naming. It seems implicit that you should use prefixes…
In gtk-fortran, there are interfaces for ~10000 GTK/GLib functions and ~2500 enums, and wa can they are systematically prefixed with the name or an abbreviation (g for GLib) of the sub-library:
[https://raw.githubusercontent.com/vmagnin/gtk-fortran/gtk4/src/gtk-fortran-index.csv](https://raw.githubusercontent.com/vmagnin/gtk-fortran/gtk4/src/gtk-fortran-index.csv)
[https://github.com/vmagnin/gtk-fortran/blob/gtk4/src/gtk-enumerators.lis](https://github.com/vmagnin/gtk-fortran/blob/gtk4/src/gtk-enumerators.lis)
Reading the GTK/GLib `.h` files, it’s also the same for `#define`, structures, etc. (those things are not imported by the gtk-fortran python wrapper).
---
### Author:  [@plevold](https://fortran-lang.discourse.group/u/plevold)
#### Post date: [November 17, 2022, 10:02am UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/17 "2022-11-17T10:02:06Z")
> [@gnikit](#):
>
> Should we attempt to reach out to some of these teams and see if they have any advice for us/lessons learned?
There’s some interesting discussions on why Cargo doesn’t have namespaces around the web. I read a bit about it a while back, but couldn’t find the exact same threads. There’s a summary here though with a lot of links that might be worth reading: [No Namespaces in Rust is a Feature :: Sam Sieber](https://samsieber.tech/posts/2020/09/registry-structure-influence/)
---
### Author:  [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)
#### Post date: [November 17, 2022, 10:18am UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/18 "2022-11-17T10:18:24Z")
> [@certik](#):
>
> prefix: we should enforce prefixes by default; and provide a command line option to opt-out;
I am sorry if I enter this discussion late, as I am no active fpm user… please discard if not meaningful.
Could fpm just itself build a unique global entry point (aka module) for each package, that wraps all public names in the package? Think
```fortran
module my_package
implicit none
! My package has potentially conflicting names
type, public :: t
character(len=12) :: x = 'Hello world!'
end type t
contains
subroutine do_sth(this)
type(t) :: this
print *, 'this = ',this
end subroutine do_sth
end module my_package
! Let fpm automatically generate this
module fpm_my_package
! Wrap all public stuff
use my_package, only: fpm_t => t
use my_package, only: fpm_do_sth => do_sth
public :: fpm_t
public :: fpm_do_sth
end module fpm_my_package
program with_fpm
use fpm_my_package
type(fpm_t) :: x
call fpm_do_sth(x)
end program with_fpm
```
---
### Author:  [@certik](https://fortran-lang.discourse.group/u/certik)
#### Post date: [November 17, 2022, 2:11pm UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/19 "2022-11-17T14:11:43Z")
> [@FedericoPerini](#):
>
> Could fpm just itself build a unique global entry point (aka module) for each package, that wraps all public names in the package?
It can. In fact this might be another nice thing to enforce possibly with warnings, to make sure every package has such a module, named as the package.
(If you are proposing this as a solution to fix the “global colliding module names” problem, then it would not fix it, as some compilers would fail.)
---
### Author:  [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)
#### Post date: [November 17, 2022, 2:23pm UTC](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720/20 "2022-11-17T14:23:27Z")
> [@certik](#):
>
> then it would not fix it, as some compilers would fail.
You mean some of the major compilers do not support renaming? If you see the global renaming module as an “almost namespace”, I think the upside would have been that for most cases, the user could just not mind; but in case his codes had collisions, they could revert to using the namespaced interface.
Also note that this interface would also work for C-bound routines I think.
[Next page](https://fortran-lang.discourse.group/t/kick-off-for-fpm-leadership-team/4720.md?page=2)