Understanding intent about fpm HOT 3 CLOSED

Hi @ShamanTcler and welcome! Thank you for starting this discussion.

Here's an excerpt from an email I sent to colleagues a few days ago. It's my answer to your question.

fpm solves the (1) user and (2) developer experience problem. I don't think it solves any technical problem. How it's implemented under the hood is details, and there are many different roads we can take. But in the design of fpm we focus on UI and UX.

1. User experience: Once fpm is installed, all that the user has to do is fpm build, fpm run, fpm test, or fpm install. This is by far the simplest UI for Fortran out there, and is aligned to what Cargo does (we designed it after Cargo exactly with UX in mind). So the only friction comes down to installing fpm. If we make this seamless--single binary executable to download--then we'll have reduced the friction to near minimum.

The key solution for here is that the user doesn't have to a) download the source code by hand; b) edit any build files; and c) download and build any dependencies by hand.

2. Developer experience: See this doc that describes the layout of an fpm package. As you can see, we take the sane default approach like Cargo where we assume a package layout and file and module naming conventions. So the developer has to remember/learn only where to put the files and how to name them. As far as I'm aware, this is the simplest developer UI for Fortran out there. Plus, the developer also gets the perk from the user experience above, which is that dependencies are automatically downloaded, built, and linked for you.

As you know, there are tools that collectively do all of the stuff that I described. However, there's no single tool that does all of what we want, and no more. Most tools were designed and intended as "the one build system/package manager to rule them all". They all fail because this is an extremely difficult problem. They also tend to be language agnostic (or at least support several different languages), so they necessarily have to be more general and handle more edge cases, which means more complex, and more complicated for the user.

Another great developer recently said "we don't need another language-specific tool". I think that's exactly what we need. Language-agnostic is what makes a tool become either too general and complex, or the design gets out of hand to reach all its objectives. Cargo is perfect for Rust. We need Cargo for Fortran.

There's also a cultural and aesthetic aspect that people rarely bring up. It's very difficult to convince a community of developers to adopt exclusively Conda, CMake, Meson, Ninja, or whatever. Conda is maybe becoming a household name in scientific Python community, but CMake is far from being a household name for Fortran. If there's a household name for Fortran, that would maybe be autotools + Make, and that's just Linux. Yes, I'm mixing up build systems and package managers here, but I'm trying to make a point, which is that we need a household name. We need a tool that, when a newcomer to Fortran visits fortran-lang.org, we can tell them here is the one tool you should use. This will only work if we have mass buy in from the community, and I think we can do this more easily if we build a Fortran-specific build system + package manager in a single tool, than trying to adopt multiple external tools.

It's easy for you and me and most people here to say "why do you need this when there are already tools X, Y, and Z". I consider myself technically literate, and I'd walk away from a project if it asked me to install Meson or Ninja. I've walked away before from Python packages that only had the Conda install instruction, and were not installable by pip. That's just me. Now imagine how it is for somebody new to Fortran, not to mention somebody new to programming.

We are targeting Fortran users across all skill levels, and especially the entry level programmers. I think it's crucial for Fortran that a new programmer who learns Fortran as their first language, loves the experience and is not scared off.

The Fortran build system + package manager must be at least as easy (and should be easier) to install and use, than it is to install and use the compiler directly.

Take a look at Fortran Discourse. I think it's the perfect format for discussions like this.

from fpm.

Thanks for the link to "FORTRAN Discourse" ... already joined. ( user CandL there)

I see mention of FORTRANCon ... good 'ole Steve Lionel is the key note, should be a good show.

Your comment "I consider myself technically literate, and I'd walk away from a project if it asked me to install Meson or Ninja." leaves me a bit perplexed ... at least regarding Ninja. I am sure this could lead to an interesting evening over a few adult beverages of your choice.

But I agree the discourse area is a better spot for this discussion. Thanks for your time and consideration.

Regards
Carl

from fpm.

Your comment "I consider myself technically literate, and I'd walk away from a project if it asked me to install Meson or Ninja." leaves me a bit perplexed ... at least regarding Ninja.

Yes, a bit of a hyperbole. If I need the project to get work done, sure. If I'm just playing, I'd pass. From Ninja's landing page, I'm not clear how it can help me. From the manual, it sounds like a faster Make. So, a tool for power users.

I am sure this could lead to an interesting evening over a few adult beverages of your choice.

I hope we get a chance to do it soon! :)

from fpm.