Hello friends, since I started looking at contributing to Fpm via GSoC2025 I’ve submitted my first PR to the project and I have a little draft proposal that I would love to discuss a little before sending in the final proposal. (discussing in this topic is probably the best place for it)
Anyways, that’s my little status-update, looking forward to chatting more 
EDIT: Here’s the TL;DR of what I’m proposing
- Add the ability for
fpm to install different versions of the same package (nested package hierarchies).
- Add a very limited form of version constraints (all constraints are of the form
>= a.b.c < (a+n).0.0 or >= 0.a.b < 0.(a+n).0).
- Implement minimal version selection, a simple and predictable constraint resolution algorithm.
1 Like
I’ve only skimmed through it really quickly, but looks good @emmabastas!
I only have a couple of comments regarding your proposal. The first one is about
There are really no complications. Currently, metapackage only accept the "*" default version. So, we just have to implement version checking. For some of them, some regex may be necessary to query a version from the package’s command wrapper, pkg-config, etc.
The second one is about versioning. fpm contains a really minimal versioning module, but we may want to look at what version-f provides already without inventing more wheels. It had been developed for the same purpose to be integrated into fpm, so it would seem like a good fit.
1 Like
Thank you for the feedback and so speedy 
. Here are my responses to the two topics you mentioned.
version-f
I looked into version-f and from my quick look it appears the we can use that to parse version constraints (including the limited set of constraints i proposed but also more expressive constraints), I updated the proposal to reflect that, thanks a lot!
metapackages
I actually do have some inklings of worries about metapackages, but I haven’t felt able to formulate them, but I will try now by formulating three assumptions that may or may not be true and then how I think that if the assumptions are true there could be some caveats that we should keep in mind:
- A dependency can itself depend on a metapackage I.e. it is possible that
my-pkg depends on pkg-a which depends on mpi.
- metapackages can have SemVer incompatible versions I.e. there can be a new version of
mpi (or some other metapackage) that’s incompatible with older versions.
- There can only be one version of a metapackage installed at one time.
If these three assumptions are true (and to some extent even if only (1) and (2) are true) then I think that we find ourselves in a situation similar to the one I described in the Exposing types from dependencies section of my proposal in the sense that we need to find a single version of mpi that satisfies all constraints! It won’t be possible to use the “escape-hatch” of installing multiple versions of a single dependency.