Next steps

[ivan-pi]

I wasn't attending to fpm very closely lately, and in the meantime it looks like the GitHub UI changed. I don't see a milestones box on top of the issues section anymore. It is now under a different button.

Apart from the big issues needed for the beta release are there any other low hanging fruits (issues) suitable as a "first project" (meaning a weekend or a few evenings)?

I've found the following one (not really an fpm project, but it might help uncover some problems):

• Candidate packages to get working Candidate packages to get working #17

Edit: I see the fpm roadmap issue was unpinned, that's why I couldn't find it.

[awvwgk]

We moved the roadmap from an issue to a milestone, which basically left an empty pinned issue back, no worth pinning this in my opinion.

[awvwgk]

Yeah, the repo got less busy with the start of this year. I spend my time at @fortran-lang mostly on stdlib's CMake integration lately, that's my “excuse” :P.

Joke aside, I think we are in serious need for a clear roadmap for fpm. The beta release milestone lists two major points for a “feature-complete” fpm, whatever this means.

1. Support for external build scripts (Support custom build script #219)
2. Compilation options by command line and/or package manifest (Managing compiler flags #112)

For the second point, I remember we didn't really agree on a specification for the package manifest yet, so I'm still hesitant to propose an implementation without an agreed upon spec. Similar the first issue is not optimal in my opinion from a package specification point of view (I questioned the current build-script structure in #249).

There are a lot of other non-roadmap issues on fpm open, each worth a lot of discussion, proposals for specs and Fortran and/or Haskell implementations.

[LKedward]

Thanks for opening the discussion @ivan-pi.

Regarding low-hanging fruit, the following issues require little or no specification decisions and so are perhaps suitable as good first issues: #242, #327, #272, #235, #252. Happy to provide guidance on any of them.
As you point out #17 is a good path for identifying further problems and increasing the fpm package ecosystem!

If you're able to provide any feedback on the latest proposed manifest syntax for managing flags that would be helpful also.

In terms of the long-term roadmap, #112 remains a priority feature to implement IMO and I understand the strong motivation for #219. However obviously the milestone is not literally set in stone and I welcome discussion on what should be prioritised going forward.

[awvwgk]

Inspired by Ondřej's (@certik) post https://fortran-lang.discourse.group/t/fortran-monthly-call-june-2021/1334/14 for a long-term goal for Fortran, I think it might be a good idea to pick up on this discussion again and think about a roadmap for fpm as well. I know this is a volunteer project (and I have insisted on this before in #416).

I think having concrete long-term goals, can help to focus efforts and provide personal motivation for contributions. For example, when I joined this project (September 2020) my personal long-term goal was to make fpm usable for the next Fortran course I was going to teach (April 2021), which I considered accomplished with the release of version 0.2.0 on conda-forge.

I haven't renewed a personal long-term goal for myself yet, but maybe it is time to put up higher goals again.

[certik]

Yes, goals for fpm is part of what I had in mind in terms of goals. Roughly, in 3 years from now, I would like:

• fpm to be the default package manager for Fortran
• All basic dependencies usable as fpm packages
• Some bigger projects converted to use fpm
• Lots of new Fortran libraries developed as fpm packages
• Large community of users and developers

We can refine these goals and make them more specific.