Transparently calling "fpm-" commands from the fpm command line interface (ie. "plug-ins")

[urbanjost]

There are pros and cons to fpm being a monolithic tool and to having subtools and/or related utilities but I believe some packages follow a model like this:

If an unknown subcommand $NAME is entered, search for a separate command in the search path called fpm-$NAME and pass the parameters to it.

This would allow for packages such as avpkg to be built independently and have different build requirements but still appear as if integrated into fpm. fman/fan might be another example (anyone have others?)

So if you build and installed avpkg (let us say it is named fpm-search) you can still call it as an independent utility but you could also call it with syntax like

fpm search 'date|time'

and if fan were named fpm-man you could call it like

fpm man merge

there are cons as well as pros, of course. fpm --list would either not list the subcommands; although listing everything named "fpm-*" in the path would be easy; fpm help manual might not include the help for the extra utilities but it would allow for fpm to concentrate on its central capabilities like package building, but allow for rapid development of subcommands like search that at least currently have distinctly different external dependencies. I could do a "pros and cons" list, and it some ways it is a nicety in that the commands can stay independent but I have tried it and like the general feel. Any other subcommands that can be reasonably developed that way that would make this more appealling?

Of course the most basic issue is name collisions with new subcommands. Next is probably that it becomes harder to pass information to and from the command to the main package without using files or some (usually) system-dependent method. And then distributing fpm has the issue of whether to include the external programs or commands to build them.

The advantages are primarily concurrent development and simplified development of commands that do not need integrated into the core and perhaps easier use of platform-specific features.

Worth pursuing? I thought I saw other packages that did that but after a cursory look for files in /usr/bin and bin starting with a $PRODUCT- name maybe it is not as common as I thought.

PS; Not quite sure if survey proposals should go into Discussions/Ideas or Issues. Maybe that should be listed at the top description. My general feeling is if it is not a concrete issue it should go here but move to issues if actual implementation begins.

[milancurcic]

I like it. This is related to, and perhaps a good approach to fpm plugins.

An fpm plugin could be a marginal functionality that is not as broadly useful to warrant it being part of core fpm, but that is very useful to at least some users.

An fpm plugin could also be used to stage and user-test experimental fpm features before they are proposed to core fpm.

avpkg is a great example (@brocolis please consider calling it "fpm-search") of what could be an fpm plugin before it's proposed as an fpm feature.

[ghost]

@milancurcic OK, avpkg is now fpm-search: https://github.com/brocolis/fpm-search/commit/7cc7dcff2646da33b6e643c74cf929cb4534eb70

[everythingfunctional]

If I'm not mistaken, this is exactly the model that git has moved towards. In fact I believe much (if not all?) of even the core functionality is no longer in the main git executable. With that kind of precedent I think it's certainly something worth exploring.

[ghost]

I like the idea. I think it'll work in this scenario:

• In a development machine I can install fpm-core and all plugins, then I write codes with all the tools I need. In the end fpm can generate a tarball.
• In a restricted environment I need only install fpm-core, then I can extract/build the tarball.

[milancurcic]

For inspiration, Cargo plugins

[urbanjost]

I think some low-hanging fruit that would fit the model like helping to build a markdown README.md file or a program to help build a TOML file as I see in the Cargo plugins would be nice. Maybe if they are developed enough they could be added to the fpm/app directory; maybe with auto-build off and them commented out in the fpm.toml file -- just thinking outloud ; but that is inspiring! I put in a prototype that makes a simple call to the external. I like calling fpm-search that way so far.

[urbanjost]

Wrote a mini-program to populate a test registry, test using --flag, and acting as a plugin called fpm-time (and to explore using Fortran as a more-portable system scripting language) and wondering if I should bother turning it into a full-blown utility( https://github.com/urbanjost/fpm-time/issues/1). Would anyone (else) use that if maintained?

It served it's intended purpose but with some work might be generally useful;. Really not sure how much shortcuts for gprof(1) and gcov(1), rr(1), valgrind(1), and such would be used or if people are using other tools instead or not doing that.

For those not familiar with them using gcov(1) gives interesting insights into what is not covered in a test/ directory; gprof(1) can give you useful timing information without having to instrument it into code yourself

This particular prototype for calling gprof(1) from fpm(1) is relatively compiler-specific too, although gprof(1) and gdb(1) work with a surprising amount of programming environments.

See also:

 fpm-search --registry 'https://github.com/urbanjost/fpm-registry/raw/master/index.json' -force-download 

[ivan-pi]

While not that common in Fortran applications, I think plug-ins are an interesting pattern that fpm could support. The GCC compiler also has it's own plugin module as do many IDE's.

CMake has a built-in functionality for plug-ins via MODULE libraries (see add_library),

MODULE libraries are plugins that are not linked into other targets but may be loaded dynamically at runtime using dlopen-like functionality.

The way I see it, users could add their own command just by placing a shared library, exposing a single procedure into a folder recognized by fpm. Currently the action performed by fpm is selected using select type and type is to pick from a fixed set of commands.

fpm/app/main.f90

Lines 70 to 87 in 6811dfe

	select type(settings=>cmd_settings)
	type is (fpm_new_settings)
	call cmd_new(settings)
	type is (fpm_build_settings)
	call cmd_build(settings)
	type is (fpm_run_settings)
	call cmd_run(settings,test=.false.)
	type is (fpm_test_settings)
	call cmd_run(settings,test=.true.)
	type is (fpm_install_settings)
	call cmd_install(settings)
	type is (fpm_update_settings)
	call cmd_update(settings)
	type is (fpm_clean_settings)
	call cmd_clean(settings)
	type is (fpm_publish_settings)
	call cmd_publish(settings)
	end select

A plugin would just become an extra case using class is (fpm_plugin_settings).

A few references:

• plug-in (software)
• Dynamically Loaded (DL) Libraries
• Notes on the Eclipse Plug-in Architecture

A few ideas for plugins:

• semantic versioning checker
• exporting Make dependencies
• drawing callgraphs (graphviz)
• linters
• AI-supported tools (ChatGPT and similar)
• static code checkers (for example Codee or fpt)
• wrapper generators (SWIG, shroud, and similar tools)