@@ -0,0 +1,466 @@ |
| 1 | +# Fortran Systems Ecosystem Landscape |
| 2 | + |
| 3 | +Date: 2026-04-21 |
| 4 | + |
| 5 | +This document is a decision aid for `FortranGoingOnForty/lib-modules`. |
| 6 | + |
| 7 | +It is not an implementation plan, and it is not trying to survey all of Fortran. It is focused on reusable systems and tooling packages that working Fortran programmers could actually depend on for shells, terminals, editors, file tools, developer tooling, local services, and command-line applications. |
| 8 | + |
| 9 | +The central question is not "can Fortran do this?" The central question is: |
| 10 | + |
| 11 | +> where does the Fortran ecosystem still lack a small, dependable, ergonomic package that an application author would realistically reach for? |
| 12 | + |
| 13 | +Package names in this document are provisional and only meant to make the backlog easier to discuss. |
| 14 | + |
| 15 | +Candidate count: `48` |
| 16 | + |
| 17 | +## Contents |
| 18 | + |
| 19 | +- [Executive Summary](#executive-summary) |
| 20 | +- [Purpose And Framing](#purpose-and-framing) |
| 21 | +- [Ecosystem Snapshot](#ecosystem-snapshot) |
| 22 | +- [How To Read The Scores](#how-to-read-the-scores) |
| 23 | +- [Category Backlog](#category-backlog) |
| 24 | +- [Organization Recommendations](#organization-recommendations) |
| 25 | +- [Local Extraction Evidence](#local-extraction-evidence) |
| 26 | +- [Sources Appendix](#sources-appendix) |
| 27 | +- [Final Read](#final-read) |
| 28 | + |
| 29 | +## Executive Summary |
| 30 | + |
| 31 | +### What The Current Landscape Looks Like |
| 32 | + |
| 33 | +- The official package index already has credible coverage for config and serialization formats, CLI parsing, logging, regex, ncurses bindings, raw POSIX wrappers, SQLite bindings, libcurl bindings, compression bindings, and many scientific utilities. |
| 34 | +- `stdlib` is also expanding into general-purpose territory. Its published scope includes utilities, logging, strings, containers, and OS or environment integration, and the current `stdlib_system` spec already covers path operations plus synchronous and asynchronous process execution. |
| 35 | +- The big gap is not "nothing exists." The big gap is that many systems-oriented areas are still split between: |
| 36 | + - thin bindings |
| 37 | + - experimental `stdlib` surfaces |
| 38 | + - personal utility collections |
| 39 | + - app-local code inside projects like `fortsh`, `fifftty`, `fortress`, `sniffert`, and `facsimile` |
| 40 | + |
| 41 | +### Highest-Signal Conclusion |
| 42 | + |
| 43 | +The strongest opportunity is still the same cluster: |
| 44 | + |
| 45 | +1. filesystem ergonomics |
| 46 | +2. subprocess and process control |
| 47 | +3. PTY and terminal state control |
| 48 | +4. file watching |
| 49 | +5. archive and compression ergonomics |
| 50 | +6. platform helpers like clipboard, "open with default app", temp files, and app-state persistence |
| 51 | + |
| 52 | +These are the places where: |
| 53 | + |
| 54 | +- real apps need the functionality repeatedly |
| 55 | +- the Fortran ecosystem has pieces, but not yet an obvious default |
| 56 | +- your own codebase already contains extractable proof that the need is real |
| 57 | + |
| 58 | +### Top Gaps |
| 59 | + |
| 60 | +- There is no obvious "default" app-author-friendly filesystem toolkit for Fortran even though filesystem APIs are actively being discussed and implemented in `stdlib`. |
| 61 | +- There is no obvious default high-level subprocess library with the kind of DX people expect from Python's `subprocess`, Rust's `std::process`, or Go's `exec`. |
| 62 | +- PTY and interactive terminal work remains very underpackaged despite being crucial for shells, terminal emulators, test harnesses, and text UIs. |
| 63 | +- File watching looks especially under-served: there are tools around the ecosystem, but no obvious reusable Fortran library that normal app authors would pull in. |
| 64 | +- Compression and archive support exists mostly as low-level bindings, not as a clean general-purpose package surface. |
| 65 | +- Persistent local app state, cache management, and workspace-state helpers are still mostly hand-rolled. |
| 66 | + |
| 67 | +### Strongest Bets Right Now |
| 68 | + |
| 69 | +These are the best "start here" candidates if the goal is maximum ecosystem value rather than novelty for its own sake. |
| 70 | + |
| 71 | +Scores are `Impact / Gap severity / Feasibility / Local leverage / Maintenance burden`. Lower maintenance burden is better. |
| 72 | + |
| 73 | +| Project | Why It Stands Out | Existing Leverage | Scores | Verdict | |
| 74 | +| --- | --- | --- | --- | --- | |
| 75 | +| `fgof-process` | Repeated need across shells, CLIs, test tools, and editors; current options are fragmented | [fortsh system interface](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fortsh/src/system/interface.f90:1) | `5/5/4/5/3` | Strong candidate | |
| 76 | +| `fgof-pty` | Rarely packaged well in Fortran, but essential for interactive tooling | [fifftty PTY manager](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fifftty/src/pty_manager.f90:1), `fortsh` interactive tests | `5/5/4/5/4` | Strong candidate | |
| 77 | +| `fgof-fs` | Biggest general-purpose gap after processes; would benefit multiple app types immediately | [sniffert file system](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/sniffert/src/file_system.f90:1), [fortress filesystem ops](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fortress/src/filesystem/fs_ops.f90:1) | `5/5/4/5/3` | Strong candidate | |
| 78 | +| `fgof-watch` | Genuine ecosystem hole; useful for dev loops, editors, sync tools, live reload | no obvious default local package yet | `5/5/3/3/4` | Strong candidate | |
| 79 | +| `fgof-lineedit` | Shells and CLIs repeatedly need it; current options are narrow or app-local | `fortsh` readline stack, editor input work | `5/5/4/5/4` | Strong candidate | |
| 80 | +| `fgof-keys` | Terminal key handling is a pain point that many apps re-solve badly | `fit`, `fortsh`, `facsimile` input handling | `4/5/4/4/3` | Strong candidate | |
| 81 | +| `fgof-clipboard` | Small, very practical, and clearly underpackaged | local clipboard code in `facsimile` | `4/5/4/4/3` | Strong candidate | |
| 82 | +| `fgof-temp` | Temp files, temp dirs, atomic writes, and safe replacement show up everywhere | `fit`, `fortress`, `facsimile` backup flows | `4/4/5/4/2` | Strong candidate | |
| 83 | +| `fgof-cache` | Local caches are useful for tools and usually hand-written badly | `fuss` cache module, command tooling | `4/5/4/4/2` | Strong candidate | |
| 84 | +| `fgof-state` | Workspace and session persistence is a repeated app need with no obvious default package | `facsimile` workspace vision | `4/5/5/4/2` | Strong candidate | |
| 85 | +| `fgof-sqlite` | Bindings exist, but an ergonomic layer would be broadly useful | existing SQLite bindings in ecosystem | `4/4/4/2/3` | Strong candidate | |
| 86 | +| `fgof-posix-core` | A curated binding layer would reduce reinvention across many future packages | `fortsh`, `sniffert`, `fit`, `fifftty` | `5/4/4/5/3` | Strong candidate | |
| 87 | +| `fgof-devloop` | There is already `fpm-watch` as a tool, but not a reusable library surface | process and watch primitives can feed it | `4/4/5/3/2` | Strong candidate | |
| 88 | + |
| 89 | +### Crowded Or Lower-Priority Areas |
| 90 | + |
| 91 | +These are not "bad ideas." They are areas where you should only enter if you have a very clear differentiator. |
| 92 | + |
| 93 | +| Area | Why It Is Lower Priority | Existing Options | |
| 94 | +| --- | --- | --- | |
| 95 | +| JSON | Multiple packages already exist | `json-fortran`, `FortJSON`, `jsonff` | |
| 96 | +| TOML | Clear ecosystem option already exists | `toml-f` | |
| 97 | +| YAML | Not empty enough to justify a me-too entry | `yaFyaml` | |
| 98 | +| CLI parsing | Several options already cover the basics well | `FLAP`, `M_CLI` | |
| 99 | +| Logging and errors | Active `stdlib` work plus multiple ecosystem packages | `stdlib_logger`, `erloff`, `fortran-error-handler`, `pFlogger` | |
| 100 | +| Regex | Solid wrapper exists already | `fortran-pcre2` | |
| 101 | +| ncurses bindings | More than one binding exists | `fortran-ncurses`, `M_ncurses` | |
| 102 | +| Raw HTTP baseline | There is already an HTTP client plus libcurl bindings | `http-client`, `fortran-curl` | |
| 103 | +| Raw OS wrappers | The ecosystem already has several low-level wrappers | `fortran-unix`, `M_system`, `os` | |
| 104 | + |
| 105 | +## Purpose And Framing |
| 106 | + |
| 107 | +This document assumes that the future `lib-modules` repo acts as an umbrella catalog repo, not a traditional monorepo: |
| 108 | + |
| 109 | +- docs and coordination live here |
| 110 | +- individual packages live in their own repos |
| 111 | +- this repo can later collect them via Git submodules |
| 112 | + |
| 113 | +That matters because it changes the target shape of good projects: |
| 114 | + |
| 115 | +- each package should be viable as a standalone `fpm` dependency |
| 116 | +- each package should have a clear surface area and release story |
| 117 | +- cross-package coupling should be optional, not structural |
| 118 | + |
| 119 | +The ideal end state is not "one giant dependency graph." It is: |
| 120 | + |
| 121 | +- a coherent family of small packages |
| 122 | +- consistent naming and conventions |
| 123 | +- clear discovery from one umbrella repo |
| 124 | +- independent adoption by people who only want one package |
| 125 | + |
| 126 | +## Ecosystem Snapshot |
| 127 | + |
| 128 | +### What Already Exists |
| 129 | + |
| 130 | +The official package index shows that Fortran already has a meaningful spread of non-numerical packages: |
| 131 | + |
| 132 | +- strings and text handling |
| 133 | +- config and serialization formats |
| 134 | +- logging and error handling |
| 135 | +- CLI argument parsing |
| 136 | +- regex |
| 137 | +- ncurses bindings |
| 138 | +- SQLite, LMDB, Lua, Tcl, Modbus, XMPP and other interfaces |
| 139 | +- libcurl, zlib, zstd and POSIX wrappers |
| 140 | + |
| 141 | +That means the right strategy is not to pretend the ecosystem is empty. The right strategy is to find the places where coverage is shallow, awkward, stale, or too low-level. |
| 142 | + |
| 143 | +### `stdlib` Is Moving Toward This Space |
| 144 | + |
| 145 | +`stdlib` already positions itself as a community general-purpose library, and the current docs show: |
| 146 | + |
| 147 | +- strings and string types |
| 148 | +- logger |
| 149 | +- containers |
| 150 | +- OS and subprocess APIs in `stdlib_system` |
| 151 | + |
| 152 | +Inference: if you build in this space, the best approach is to complement `stdlib`, align where it helps, and avoid fighting it head-on in areas where it is already the natural default. |
| 153 | + |
| 154 | +### Why Your Local Codebase Matters |
| 155 | + |
| 156 | +Your local projects are not toy examples. They are real end-user tools: |
| 157 | + |
| 158 | +- shell: `fortsh` |
| 159 | +- terminal emulator: `fifftty` |
| 160 | +- file explorer: `fortress` |
| 161 | +- disk analyzer: `sniffert` |
| 162 | +- editor and workspace tooling: `facsimile` |
| 163 | +- merge tool / TUI tooling: `fit` |
| 164 | +- tree and git helper tooling: `fuss` |
| 165 | + |
| 166 | +Those projects repeatedly need: |
| 167 | + |
| 168 | +- filesystem traversal and metadata |
| 169 | +- subprocess and job control |
| 170 | +- PTY interaction |
| 171 | +- terminal state management |
| 172 | +- clipboard and prompt helpers |
| 173 | +- persistent workspace or tool state |
| 174 | + |
| 175 | +That makes extraction-based packages unusually credible here. These are not hypothetical package ideas; they are recurring needs that have already been paid for in app code. |
| 176 | + |
| 177 | +## How To Read The Scores |
| 178 | + |
| 179 | +Every candidate uses the same five scores: |
| 180 | + |
| 181 | +- `Impact`: how broadly useful this would be to app authors |
| 182 | +- `Gap severity`: how underserved the area still looks |
| 183 | +- `Feasibility`: how likely it is to ship something solid without heroic effort |
| 184 | +- `Local leverage`: how much existing FortranGoingOnForty code or tests could accelerate it |
| 185 | +- `Maintenance burden`: how expensive it will be to support over time |
| 186 | + |
| 187 | +Interpretation: |
| 188 | + |
| 189 | +- higher is better for `Impact`, `Gap severity`, `Feasibility`, and `Local leverage` |
| 190 | +- lower is better for `Maintenance burden` |
| 191 | + |
| 192 | +Verdicts: |
| 193 | + |
| 194 | +- `Strong candidate`: worth serious consideration soon |
| 195 | +- `Worth exploring`: promising, but needs sharper differentiation or depends on upstream choices |
| 196 | +- `Low priority`: possible someday, but not where the leverage is right now |
| 197 | + |
| 198 | +## Category Backlog |
| 199 | + |
| 200 | +### 1. Filesystem And Paths |
| 201 | + |
| 202 | +Takeaway: the ecosystem has pieces here, but not yet a clear ergonomic default for app authors. |
| 203 | + |
| 204 | +| Project | Pitch And Problem Solved | Why The Gap Remains | Existing Options | Recommended Shape | Dependency Story | Local Leverage | Scores | Verdict | |
| 205 | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | |
| 206 | +| `fgof-path` | Path type plus joins, normalize, relatives, basename, dirname, tilde and home handling | Path helpers exist, but they are either low-level or experimental rather than a polished everyday API | `stdlib_system`, `M_IO`, `M_system`, `os` | ergonomic facade | mostly pure Fortran | [fortress filesystem ops](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fortress/src/filesystem/fs_ops.f90:1), [sniffert file system](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/sniffert/src/file_system.f90:1) | `4/4/5/4/2` | Strong candidate | |
| 207 | +| `fgof-fs` | `stat`, `lstat`, `exists`, `scandir`, `walk`, metadata, symlink handling, permissions | There are wrappers, but not an obvious small package people would confidently standardize on | `stdlib_system`, `fortran-unix`, `fortyxima`, `os` | ergonomic facade | POSIX C shim first | [fortsh system interface](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fortsh/src/system/interface.f90:1), [sniffert file system](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/sniffert/src/file_system.f90:1), [fortress filesystem ops](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fortress/src/filesystem/fs_ops.f90:1) | `5/5/4/5/3` | Strong candidate | |
| 208 | +| `fgof-temp` | Temp files, temp dirs, atomic write or replace, safe move semantics | Almost every tool needs this and almost every tool hand-rolls it | no obvious default package surfaced in official index | new implementation | pure Fortran plus OS calls | `fit` temp-file flows, `fortress` scratch files, `facsimile` backup ideas | `4/4/5/4/2` | Strong candidate | |
| 209 | +| `fgof-trash-open` | Trash files safely, reveal paths, open with default app, launch file manager | Very practical, clearly useful, and not obviously covered by a standard package | no obvious default package surfaced in official index | new implementation | shell or C shims by platform | [fortress filesystem ops](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fortress/src/filesystem/fs_ops.f90:1), [sniffert file system](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/sniffert/src/file_system.f90:1) | `4/5/4/4/3` | Strong candidate | |
| 210 | +| `fgof-xdg` | Config, cache, state, runtime-dir discovery for CLI and TUI apps | Every serious app repeats this logic; existing wrappers stop at environment access | `M_system`, raw env helpers | new implementation | pure Fortran | [facsimile workspace vision](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/facsimile/docs/WORKSPACE_VISION.md:1) | `3/4/5/4/1` | Worth exploring | |
| 211 | +| `fgof-ignore` | `.gitignore`-style rules, include or exclude filters, reusable path selection engine | Globbing is not the same as ignore semantics, and tooling authors often need the latter | local `fortsh` globbing, regex packages | extracted module or new implementation | pure Fortran | `fortsh` glob parser, `fuss` tree scanning | `4/4/4/4/2` | Worth exploring | |
| 212 | + |
| 213 | +### 2. Processes And Jobs |
| 214 | + |
| 215 | +Takeaway: this is one of the strongest clusters in the whole document. |
| 216 | + |
| 217 | +| Project | Pitch And Problem Solved | Why The Gap Remains | Existing Options | Recommended Shape | Dependency Story | Local Leverage | Scores | Verdict | |
| 218 | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | |
| 219 | +| `fgof-process` | High-level `run`, `spawn`, capture, timeouts, cwd, env overrides, exit status | `stdlib` and wrappers exist, but there is still no obvious ergonomic default for apps and tests | `stdlib_system`, `M_process`, `M_system`, `fortran-unix` | ergonomic facade | POSIX first with C shim | [fortsh system interface](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fortsh/src/system/interface.f90:1) and executor stack | `5/5/4/5/3` | Strong candidate | |
| 220 | +| `fgof-cmd` | Safe argv construction and shell quoting helpers to stop command-string bugs | Command construction is still mostly hand-built strings | ad hoc code; general wrappers do not center this | new implementation | pure Fortran | `fortress` git command building, `fortsh` parser and execution model | `4/4/5/4/1` | Strong candidate | |
| 221 | +| `fgof-env` | Environment variables, executable lookup, PATH resolution, cwd stack helpers | Existing wrappers expose pieces, but not a small opinionated convenience layer | `M_system`, `stdlib_system`, `fortran-unix` | ergonomic facade | pure Fortran plus OS calls | `fortress`, `facsimile`, `fortsh` startup logic | `3/3/5/4/1` | Worth exploring | |
| 222 | +| `fgof-jobs` | Background jobs, process groups, wait models, pipeline status tracking | Shells need this; most general packages do not even try to expose it well | local shell code only; low-level POSIX bindings | extracted module | POSIX only at first | `fortsh` jobs and signal handling | `4/5/3/5/4` | Strong candidate | |
| 223 | +| `fgof-proc-test` | Test fixtures for child processes, retry loops, cleanup, capture, fail-fast helpers | General test frameworks exist, but process-fixture tooling is thin | `test-drive`, `vegetables`, `pFUnit` do not specialize here | new implementation | `fgof-process` backend | `fortsh` integration tests and runner logic | `4/5/4/5/3` | Strong candidate | |
| 224 | + |
| 225 | +### 3. PTY And Terminal Control |
| 226 | + |
| 227 | +Takeaway: this is unusually underpackaged given how important it is for interactive tools. |
| 228 | + |
| 229 | +| Project | Pitch And Problem Solved | Why The Gap Remains | Existing Options | Recommended Shape | Dependency Story | Local Leverage | Scores | Verdict | |
| 230 | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | |
| 231 | +| `fgof-pty` | PTY sessions, child attach, reads and writes, resize, close, signal delivery | This capability is critical for shells and terminals but still mostly app-local | no obvious general-purpose default in official index | extracted module or ergonomic facade | POSIX C shim | [fifftty PTY manager](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fifftty/src/pty_manager.f90:1), `fortsh` interactive harnesses | `5/5/4/5/4` | Strong candidate | |
| 232 | +| `fgof-termios` | Raw and canonical mode guards, echo restore, cursor restore safety | Terminal mode handling is low-level and error-prone | `fortran-unix` and raw POSIX only | ergonomic facade | POSIX C shim | [fortsh system interface](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fortsh/src/system/interface.f90:1), `fit` keyboard handling | `4/4/5/5/2` | Strong candidate | |
| 233 | +| `fgof-ttysize` | Terminal size querying, resize propagation, helper APIs for UI layouts | This logic appears all over interactive tools, but rarely as a standalone package | low-level ioctl wrappers only | small utility package | POSIX first | `fortsh`, `fifftty`, `fit` terminal sizing code | `3/4/5/4/2` | Worth exploring | |
| 234 | +| `fgof-expect` | Expect-style PTY testing library for scripted interactions | Great fit for shells, TUIs, terminal apps, and CI; ecosystem surface is tiny | no obvious general-purpose default in official index | new implementation | `fgof-pty` backend | `fortsh` interactive YAML specs, `fifftty` tests | `4/5/4/5/3` | Strong candidate | |
| 235 | + |
| 236 | +### 4. Terminal UX And TUI Primitives |
| 237 | + |
| 238 | +Takeaway: the ecosystem has low-level pieces, but a lot of day-to-day TUI ergonomics are still hand-built. |
| 239 | + |
| 240 | +| Project | Pitch And Problem Solved | Why The Gap Remains | Existing Options | Recommended Shape | Dependency Story | Local Leverage | Scores | Verdict | |
| 241 | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | |
| 242 | +| `fgof-ansi` | Styles, cursor movement, alternate screen, clear regions, restore helpers | ANSI codes exist in `stdlib`, but many apps still want a friendlier composition layer | `stdlib_ansi`, app-local snippets | ergonomic facade | pure Fortran | `fortsh`, `facsimile`, `fortress`, `fit` | `3/3/5/5/1` | Worth exploring | |
| 243 | +| `fgof-keys` | Normalize escape sequences and terminal key decoding across terminals | Everyone reinvents this differently, and it is brittle | ncurses or custom parsing; no obvious standalone default | new implementation | pure Fortran plus termios helpers | `fit`, `fortsh`, `facsimile` input work | `4/5/4/4/3` | Strong candidate | |
| 244 | +| `fgof-lineedit` | History, kill/yank, completion hooks, prompt editing for CLI tools | Readline integration exists, but a clean Fortran-native line editor surface is still rare | local readline wrappers, `M_history` | extracted module or new implementation | termios plus terminal I/O | `fortsh` I/O stack, editor input ideas | `5/5/4/5/4` | Strong candidate | |
| 245 | +| `fgof-clipboard` | Cross-platform clipboard get and set for text tools | Small but useful package with clear practical demand | no obvious default package in official index | extracted module | shell tools by platform | `facsimile` clipboard module | `4/5/4/4/3` | Strong candidate | |
| 246 | +| `fgof-prompt` | Menus, confirm prompts, pickers, spinners, progress, forms | Useful to many CLI and TUI tools, but usually bolted onto apps | CLI parsers cover args, not interactive prompts | new implementation | pure Fortran | `fortress` UI, `sniffert` UI, `fit` TUI layout | `3/4/4/4/2` | Worth exploring | |
| 247 | +| `fgof-screen` | Virtual screen buffer and diff renderer for TUIs | ncurses bindings exist, but a higher-level compositional model does not clearly dominate | `fortran-ncurses`, `M_ncurses` | ergonomic facade | can sit on ANSI or ncurses | `sniffert` terminal UI, `fifftty` terminal grid, `facsimile` rendering code | `4/4/3/4/4` | Worth exploring | |
| 248 | + |
| 249 | +### 5. Filesystem Watching |
| 250 | + |
| 251 | +Takeaway: this is one of the clearest "library gap" areas in the whole document. |
| 252 | + |
| 253 | +| Project | Pitch And Problem Solved | Why The Gap Remains | Existing Options | Recommended Shape | Dependency Story | Local Leverage | Scores | Verdict | |
| 254 | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | |
| 255 | +| `fgof-watch` | High-level watch API with native backends and polling fallback | There are tools and external libraries, but no obvious reusable Fortran default for app authors | `fpm-watch` is a tool, not a library; no obvious package-index default | ergonomic facade | native backends via C or libfswatch | future editor and dev-loop use across local tools | `5/5/3/3/4` | Strong candidate | |
| 256 | +| `fgof-watch-poll` | Pure polling backend for portability, CI, and fallback behavior | Native watchers are complex; polling still has value as a reliable baseline | no obvious package-index default | new implementation | pure Fortran | useful for any future watch-based package | `3/4/5/2/2` | Worth exploring | |
| 257 | +| `fgof-watch-rules` | Ignore rules, debounce, coalescing, event filtering | Real watchers need event shaping; many libraries stop at raw notifications | app authors usually reimplement this themselves | library sidecar | pure Fortran | combines well with `fgof-ignore` and `fgof-watch` | `3/4/4/2/2` | Worth exploring | |
| 258 | +| `fgof-devloop` | Auto restart and rebuild supervision library for tools and tests | There is visible demand for watch-driven dev loops, but the reusable library layer is missing | `fpm-watch` as a tool | new implementation | `fgof-watch` plus `fgof-process` | useful for local tool development and CI smoke loops | `4/4/5/3/2` | Strong candidate | |
| 259 | + |
| 260 | +### 6. Networking And Services |
| 261 | + |
| 262 | +Takeaway: this space is not empty, but it is still mostly thin bindings plus isolated projects. |
| 263 | + |
| 264 | +| Project | Pitch And Problem Solved | Why The Gap Remains | Existing Options | Recommended Shape | Dependency Story | Local Leverage | Scores | Verdict | |
| 265 | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | |
| 266 | +| `fgof-http` | Friendlier HTTP client with requests, headers, forms, timeouts, and composable responses | HTTP exists, but ecosystem default status and ergonomics still look unsettled | `http-client`, `fortran-curl` | ergonomic facade | libcurl backend likely | useful to future package tooling and local service clients | `4/3/4/2/3` | Worth exploring | |
| 267 | +| `fgof-url` | URL parsing, joining, encoding, decoding, query building | Useful even outside HTTP, and not clearly solved by a common package | no obvious default package surfaced in official index | new implementation | pure Fortran | can support HTTP and service tooling later | `3/4/5/1/1` | Worth exploring | |
| 268 | +| `fgof-tcp` | Simple TCP client or server API for tools and local services | Package-index coverage looks more demo-like and binding-like than ergonomic | `tcp-client-server`, `fortran-unix` | ergonomic facade | POSIX sockets or C shim | could support future dev tools and editor integrations | `4/4/4/2/3` | Worth exploring | |
| 269 | +| `fgof-tls` | Secure socket helpers, certificate loading, client defaults | Important, but hard and expensive, especially cross-platform | raw OpenSSL world only | thin binding first, if at all | OpenSSL or similar | little local leverage yet | `4/5/2/1/5` | Low priority | |
| 270 | +| `fgof-websocket` | WebSocket client for live tools, streaming APIs, and dashboards | No obvious Fortran default surfaced in official package landscape | no obvious package-index default | new implementation | handshake, framing, and likely TLS | little local leverage yet | `4/5/2/1/5` | Low priority | |
| 271 | +| `fgof-service` | Daemon or service lifecycle helpers, pidfile, signal glue, status checks | A niche but useful layer for people writing long-running local services | process libraries expose pieces, not a full shape | new implementation | `fgof-process` and signals | `fortsh` signal and job work | `3/4/4/3/3` | Worth exploring | |
| 272 | + |
| 273 | +### 7. Storage And Local Data |
| 274 | + |
| 275 | +Takeaway: bindings exist here; ergonomic local-tool persistence packages mostly do not. |
| 276 | + |
| 277 | +| Project | Pitch And Problem Solved | Why The Gap Remains | Existing Options | Recommended Shape | Dependency Story | Local Leverage | Scores | Verdict | |
| 278 | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | |
| 279 | +| `fgof-sqlite` | Friendly query and transaction layer on top of SQLite bindings | SQLite bindings exist, but the "pleasant to use in an app" layer is still open | `fortran-sqlite3`, `sqliteff` | ergonomic facade | SQLite C library | future workspace, cache, and metadata tooling | `4/4/4/2/3` | Strong candidate | |
| 280 | +| `fgof-kv` | Tiny embedded key-value store API backed by SQLite or LMDB | Tool authors often want simple persistence, not a full SQL surface | `fortran-lmdb` is low-level | ergonomic facade | SQLite or LMDB backend | can power caches and tool state | `4/4/4/2/3` | Worth exploring | |
| 281 | +| `fgof-cache` | Disk cache with content hashing, TTLs, invalidation, and cleanup | Extremely useful for CLI tools and build-ish workflows; mostly hand-rolled today | no obvious default package surfaced in official index | new implementation | pure plus filesystem helpers | `fuss` cache ideas and tooling workflows | `4/5/4/4/2` | Strong candidate | |
| 282 | +| `fgof-state` | Persistent app, session, and workspace state with atomic saves and versioning | Editors, shells, and file tools need this repeatedly, and config parsers alone do not solve it | config packages exist, but not a state-management default | new implementation | pure plus filesystem helpers | [facsimile workspace vision](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/facsimile/docs/WORKSPACE_VISION.md:1) | `4/5/5/4/2` | Strong candidate | |
| 283 | + |
| 284 | +### 8. Archives And Compression |
| 285 | + |
| 286 | +Takeaway: low-level coverage exists, but the package-author-friendly layer still looks open. |
| 287 | + |
| 288 | +| Project | Pitch And Problem Solved | Why The Gap Remains | Existing Options | Recommended Shape | Dependency Story | Local Leverage | Scores | Verdict | |
| 289 | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | |
| 290 | +| `fgof-archive` | Single high-level API for tar and zip style archive creation and extraction | Compression bindings exist, but not an obvious archive package people would instinctively use | `fortran-zlib`, `fortran-zstd` are lower-level | ergonomic facade | `libarchive` or bespoke backends | useful across packaging and artifact tools | `4/5/3/1/4` | Strong candidate | |
| 291 | +| `fgof-compress` | Simple gzip and zstd compress/decompress functions and streams | The raw bindings are not the same thing as a pleasant package surface | `fortran-zlib`, `fortran-zstd` | ergonomic facade | zlib or zstd backend | would support archives and caching | `4/4/4/1/3` | Worth exploring | |
| 292 | +| `fgof-checksum` | File and buffer digests for SHA-256 or similar | Great utility layer for caches, archives, snapshots, and integrity checks | no obvious package-index default surfaced | new implementation | C crypto backend likely | cross-cutting utility for many later packages | `3/4/4/1/3` | Worth exploring | |
| 293 | +| `fgof-pack` | Bundle manifests plus files into reproducible tool artifacts | Useful for release tooling and app bundles, but more specialized than base archive work | no obvious package-index default surfaced | new implementation | archive plus checksum backends | future release and packaging workflows | `3/3/3/1/3` | Worth exploring | |
| 294 | + |
| 295 | +### 9. Developer Tooling |
| 296 | + |
| 297 | +Takeaway: this is fertile ground because tooling libraries often have high leverage and lower platform pain. |
| 298 | + |
| 299 | +| Project | Pitch And Problem Solved | Why The Gap Remains | Existing Options | Recommended Shape | Dependency Story | Local Leverage | Scores | Verdict | |
| 300 | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | |
| 301 | +| `fgof-snapshot` | Snapshot or golden-file testing helpers for CLIs and diagnostics | Existing test frameworks do not specialize in this workflow | `test-drive`, `vegetables`, `pFUnit` | new implementation | pure Fortran | snapshot-like local tests in `armfortas` and CLI tools | `4/5/5/3/2` | Strong candidate | |
| 302 | +| `fgof-fixture` | Temp project, temp worktree, and fixture builders for tests | Process-heavy tools need better test fixtures than raw shell setup | general test frameworks exist, but not this niche | new implementation | filesystem plus process helpers | `fortsh`, `fit`, and other test suites | `4/4/5/3/2` | Strong candidate | |
| 303 | +| `fgof-parser` | General parser combinators and token-stream library | Parsers exist, but reusable general parser infrastructure is still thin | `parff`, equation parsers | new implementation or extracted core | pure Fortran | `fortsh` parser stack is strong evidence | `4/4/4/5/3` | Strong candidate | |
| 304 | +| `fgof-modulegraph` | Build module-dependency graph for Fortran source trees | Useful for tooling and editors; current options are more tool-like than library-like | `FortranCallGraph`, `fortls`, external parsers | new implementation | pure Fortran | future workspace tooling in `facsimile` | `3/4/4/2/2` | Worth exploring | |
| 305 | +| `fgof-trace` | Structured timing and tracing spans for CLIs, tests, and services | Logging exists, but trace-style instrumentation is still sparse | `stdlib_logger`, `coretran`, `pFlogger` | new implementation | pure Fortran | `fortsh` performance helpers | `3/3/5/3/1` | Worth exploring | |
| 306 | + |
| 307 | +### 10. Interop And Bindings |
| 308 | + |
| 309 | +Takeaway: low-level wrappers are not glamorous, but a few carefully chosen ones could unlock many higher-level packages. |
| 310 | + |
| 311 | +| Project | Pitch And Problem Solved | Why The Gap Remains | Existing Options | Recommended Shape | Dependency Story | Local Leverage | Scores | Verdict | |
| 312 | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | |
| 313 | +| `fgof-posix-core` | Curated POSIX core for files, dirs, fd I/O, processes, signals, and terminals | Low-level wrappers exist, but coverage and naming are inconsistent and often not shaped for reuse | `fortran-unix`, `M_system`, `os` | thin binding with sane naming | POSIX C APIs | [fortsh system interface](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fortsh/src/system/interface.f90:1), [sniffert file system](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/sniffert/src/file_system.f90:1), [fifftty PTY manager](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fifftty/src/pty_manager.f90:1) | `5/4/4/5/3` | Strong candidate | |
| 314 | +| `fgof-cstr` | Safe C-string, argv, and buffer conversion helpers for `iso_c_binding` work | Every wrapper package ends up reinventing this small but annoying layer | raw `iso_c_binding` plus scattered discourse advice | thin utility package | pure Fortran | nearly every local C-interop-heavy repo | `4/4/5/5/1` | Strong candidate | |
| 315 | +| `fgof-libfswatch` | Thin binding to `libfswatch` for future watcher packages | Useful enabler, but not the highest-value user-facing package by itself | no obvious Fortran binding surfaced in official package index | thin binding | external `libfswatch` | prerequisite for some watch strategies | `3/4/3/1/4` | Worth exploring | |
| 316 | +| `fgof-openssl-bind` | Thin OpenSSL binding foundation for TLS and hashing | Potentially useful, but expensive and fiddly to support well | no obvious general-purpose Fortran binding surfaced in official package index | thin binding | OpenSSL | little local leverage today | `4/5/2/1/5` | Low priority | |
| 317 | + |
| 318 | +## Organization Recommendations |
| 319 | + |
| 320 | +### Recommended Repo Shape |
| 321 | + |
| 322 | +Use `lib-modules` as an umbrella repo: |
| 323 | + |
| 324 | +```text |
| 325 | +lib-modules/ |
| 326 | + LANDSCAPE.md |
| 327 | + packages/ |
| 328 | + fgof-fs/ # git submodule |
| 329 | + fgof-process/ # git submodule |
| 330 | + fgof-pty/ # git submodule |
| 331 | + ... |
| 332 | +``` |
| 333 | + |
| 334 | +This is not a classic monorepo. It is better described as: |
| 335 | + |
| 336 | +- a catalog repo |
| 337 | +- shared docs and roadmap |
| 338 | +- independent package repos collected via Git submodules |
| 339 | + |
| 340 | +That choice fits your stated organizational preference and keeps package adoption simple for outsiders. |
| 341 | + |
| 342 | +### Independent Package Defaults |
| 343 | + |
| 344 | +Every serious package should aim to be: |
| 345 | + |
| 346 | +- its own repository |
| 347 | +- its own `fpm` package |
| 348 | +- independently versioned |
| 349 | +- independently releasable |
| 350 | +- independently listable in the Fortran package index |
| 351 | + |
| 352 | +### Naming Recommendations |
| 353 | + |
| 354 | +Use a consistent prefix to avoid module collisions. |
| 355 | + |
| 356 | +Provisional recommendation: |
| 357 | + |
| 358 | +- repo names: `fgof-fs`, `fgof-process`, `fgof-pty` |
| 359 | +- top-level module prefix: `fgof_` |
| 360 | + |
| 361 | +Example: |
| 362 | + |
| 363 | +- repo: `fgof-process` |
| 364 | +- modules: `fgof_process`, `fgof_process_types`, `fgof_process_test` |
| 365 | + |
| 366 | +### Release And Dependency Recommendations |
| 367 | + |
| 368 | +- keep packages standalone by default |
| 369 | +- avoid cross-package dependencies until a real need appears |
| 370 | +- if cross-package dependencies become useful, prefer a shallow graph: |
| 371 | + - foundational packages first |
| 372 | + - ergonomic facades on top |
| 373 | +- give each package: |
| 374 | + - `README.md` |
| 375 | + - examples |
| 376 | + - tests |
| 377 | + - CI |
| 378 | + - explicit compiler support notes |
| 379 | + |
| 380 | +### Practical Sequencing |
| 381 | + |
| 382 | +If you decide to build from this document later, the most sensible first-wave sequence looks like: |
| 383 | + |
| 384 | +1. `fgof-posix-core` |
| 385 | +2. `fgof-fs` |
| 386 | +3. `fgof-process` |
| 387 | +4. `fgof-pty` |
| 388 | +5. `fgof-lineedit` or `fgof-watch` |
| 389 | + |
| 390 | +That sequence maximizes reuse and minimizes duplicate low-level work. |
| 391 | + |
| 392 | +## Local Extraction Evidence |
| 393 | + |
| 394 | +These local files are especially strong signals that the package surface is not hypothetical: |
| 395 | + |
| 396 | +- [fortsh system interface](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fortsh/src/system/interface.f90:1) |
| 397 | +- [fifftty PTY manager](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fifftty/src/pty_manager.f90:1) |
| 398 | +- [fortress filesystem ops](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fortress/src/filesystem/fs_ops.f90:1) |
| 399 | +- [sniffert file system](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/sniffert/src/file_system.f90:1) |
| 400 | +- [facsimile workspace vision](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/facsimile/docs/WORKSPACE_VISION.md:1) |
| 401 | +- [facsimile fortress integration plan](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/facsimile/docs/fortress_integration.md:1) |
| 402 | + |
| 403 | +Inference from those files: |
| 404 | + |
| 405 | +- filesystem and path handling recur across multiple apps |
| 406 | +- terminal state and PTY handling are already deep enough locally to extract |
| 407 | +- workspace state, config locations, prompts, and app-state persistence are not theoretical needs |
| 408 | +- integration tests for interactive tools could directly benefit from reusable PTY and process-test packages |
| 409 | + |
| 410 | +## Sources Appendix |
| 411 | + |
| 412 | +### Official Ecosystem Sources |
| 413 | + |
| 414 | +- [Fortran package index](https://fortran-lang.org/packages/) |
| 415 | +- [General libraries](https://fortran-lang.org/packages/libraries/) |
| 416 | +- [I/O packages](https://fortran-lang.org/packages/io/) |
| 417 | +- [Interface packages](https://fortran-lang.org/packages/interfaces/) |
| 418 | +- [Programming utilities](https://fortran-lang.org/packages/programming/) |
| 419 | +- [String libraries](https://fortran-lang.org/packages/strings/) |
| 420 | +- [Data-type libraries](https://fortran-lang.org/packages/data-types/) |
| 421 | + |
| 422 | +### `stdlib` Sources |
| 423 | + |
| 424 | +- [Fortran stdlib landing page](https://stdlib.fortran-lang.org/) |
| 425 | +- [Fortran stdlib specs index](https://stdlib.fortran-lang.org/page/specs/index.html) |
| 426 | +- [Fortran stdlib system spec](https://stdlib.fortran-lang.org/page/specs/stdlib_system.html) |
| 427 | +- [Fortran stdlib logger spec](https://stdlib.fortran-lang.org/page/specs/stdlib_logger.html) |
| 428 | + |
| 429 | +### Community Discussions And Announcements |
| 430 | + |
| 431 | +- [Stdlib system interaction API: call for feedback](https://fortran-lang.discourse.group/t/stdlib-system-interaction-api-call-for-feedback/9037) |
| 432 | +- [GSoC '25: stdlib filesystem](https://fortran-lang.discourse.group/t/gsoc-25-stdlib-filesystem/9798) |
| 433 | +- [GSOC Intro - stdlib File system library, OS processes](https://fortran-lang.discourse.group/t/gsoc-intro-stdlib-file-system-library-os-processes/9295) |
| 434 | +- [GSoC 2026 Introduction: interested in stdlib file system library](https://fortran-lang.discourse.group/t/gsoc-2026-introduction-jatin-kumar-interested-in-stdlib-file-system-library/10712) |
| 435 | +- [New Release of http-client](https://fortran-lang.discourse.group/t/new-release-of-http-client-enhancing-http-requests-in-fortran/6407) |
| 436 | +- [Troubleshooting dependency issues with http-client](https://fortran-lang.discourse.group/t/troubleshooting-dependency-issues-with-http-client-in-fpm-projects-resolving-stdlib-optval-error/6196) |
| 437 | +- [New fpm Plugin: fpm-watch](https://fortran-lang.discourse.group/t/new-fpm-plugin-fpm-watch/10753) |
| 438 | +- [Will the Fortran Community participate at GSoC 2024?](https://fortran-lang.discourse.group/t/will-the-fortran-community-participate-at-gsoc-2024/7266) |
| 439 | + |
| 440 | +### Local Evidence |
| 441 | + |
| 442 | +- [fortsh README](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fortsh/README.md:1) |
| 443 | +- [facsimile README](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/facsimile/README.md:1) |
| 444 | +- [fortress README](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fortress/README.md:1) |
| 445 | +- [fifftty README](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fifftty/README.md:1) |
| 446 | +- [fuss README](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fuss/README.md:1) |
| 447 | +- [fit README](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fit/README.md:1) |
| 448 | + |
| 449 | +## Final Read |
| 450 | + |
| 451 | +If the goal is to close one of the most visible non-numerical gaps in the Fortran ecosystem, the best lane is not "write a random library." It is: |
| 452 | + |
| 453 | +- extract and harden the systems layers your apps already need |
| 454 | +- package them so they stand alone cleanly |
| 455 | +- prefer ergonomic facades where the ecosystem already has low-level coverage |
| 456 | +- avoid crowded categories unless you have a very sharp differentiator |
| 457 | + |
| 458 | +The practical center of gravity remains: |
| 459 | + |
| 460 | +- filesystem |
| 461 | +- process control |
| 462 | +- PTY and terminal control |
| 463 | +- watch or dev-loop tooling |
| 464 | +- persistence and local app state |
| 465 | + |
| 466 | +That is the area where Fortran still looks most ready for a coherent family of packages rather than one more isolated project. |
