# Proposal draft (feedback wanted) -- Fpm constraint resolution

**URL:** <https://fortran-lang.discourse.group/t/proposal-draft-feedback-wanted-fpm-constraint-resolution/9478>\
**Category:** GSoC-2025\
**Created:** [March 25, 2025, 4:26pm UTC](https://fortran-lang.discourse.group/t/proposal-draft-feedback-wanted-fpm-constraint-resolution/9478 "2025-03-25T16:26:06Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![emmabastas](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/emmabastas/32/5736_2.png) [@emmabastas](https://fortran-lang.discourse.group/u/emmabastas)\
**Post date:** [March 25, 2025, 4:26pm UTC](https://fortran-lang.discourse.group/t/proposal-draft-feedback-wanted-fpm-constraint-resolution/9478/1 "2025-03-25T16:26:06Z")

</div>

Hello friends, since I [started looking](https://fortran-lang.discourse.group/t/gsoc-intro-fpm-version-constraint-resolution/9272/) at contributing to Fpm via GSoC2025 I’ve submitted [my first PR](https://github.com/fortran-lang/fpm/pull/1116) to the project and I have a little [draft proposal](https://gist.github.com/emmabastas/80b016dacbc2cafc5c5f3b8117eaeb17) 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](https://research.swtch.com/vgo), a simple and predictable constraint resolution algorithm.

---

<div class="post-metadata">

**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\
**Post date:** [March 25, 2025, 6:06pm UTC](https://fortran-lang.discourse.group/t/proposal-draft-feedback-wanted-fpm-constraint-resolution/9478/2 "2025-03-25T18:06:07Z")

</div>

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

> [@](#):
>
> TODO: metapackages  
> Are there complications related to meta-packages? I don’t know a lot about them.

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](https://github.com/minhqdao/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.

---

<div class="post-metadata">

**Author:** ![emmabastas](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/emmabastas/32/5736_2.png) [@emmabastas](https://fortran-lang.discourse.group/u/emmabastas)\
**Post date:** [March 25, 2025, 11:23pm UTC](https://fortran-lang.discourse.group/t/proposal-draft-feedback-wanted-fpm-constraint-resolution/9478/3 "2025-03-25T23:23:09Z")

</div>

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:

1. **A dependency can itself depend on a metapackage** I.e. it is possible that `my-pkg` depends on `pkg-a` which depends on `mpi`.
2. **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.
3. **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](https://gist.github.com/emmabastas/80b016dacbc2cafc5c5f3b8117eaeb17#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.