@@ -14,6 +14,8 @@ Package names in this document are provisional and only meant to make the backlo |
| 14 | 14 | |
| 15 | 15 | Candidate count: `48` |
| 16 | 16 | |
| 17 | +Status note: `fgof-process`, `fgof-fs`, `fgof-pty`, and `fgof-lineedit` have now shipped as `v0.1.0` packages. They remain in the backlog tables as completed reference points so the original scoring context stays visible. |
| 18 | + |
| 17 | 19 | ## Contents |
| 18 | 20 | |
| 19 | 21 | - [Executive Summary](#executive-summary) |
@@ -30,6 +32,7 @@ Candidate count: `48` |
| 30 | 32 | |
| 31 | 33 | ### What The Current Landscape Looks Like |
| 32 | 34 | |
| 35 | +- The first FortranGoingOnForty wave is now real, not hypothetical: `fgof-process`, `fgof-fs`, `fgof-pty`, and `fgof-lineedit` are shipped and establish a credible baseline for process, filesystem, PTY, and interactive editing work. |
| 33 | 36 | - 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 | 37 | - `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 | 38 | - The big gap is not "nothing exists." The big gap is that many systems-oriented areas are still split between: |
@@ -40,50 +43,65 @@ Candidate count: `48` |
| 40 | 43 | |
| 41 | 44 | ### Highest-Signal Conclusion |
| 42 | 45 | |
| 43 | | -The strongest opportunity is still the same cluster: |
| 46 | +The first wave is now shipped: |
| 47 | + |
| 48 | +1. subprocess and process control via `fgof-process` |
| 49 | +2. filesystem ergonomics via `fgof-fs` |
| 50 | +3. PTY session control via `fgof-pty` |
| 51 | +4. line editing primitives via `fgof-lineedit` |
| 44 | 52 | |
| 45 | | -1. filesystem ergonomics |
| 46 | | -2. subprocess and process control |
| 47 | | -3. PTY and terminal state control |
| 48 | | -4. file watching |
| 53 | +The strongest remaining opportunity cluster now looks like: |
| 54 | + |
| 55 | +1. file watching |
| 56 | +2. terminal state and key normalization |
| 57 | +3. expect-style testing and process-test tooling |
| 58 | +4. temp, cache, clipboard, and app-state helpers |
| 49 | 59 | 5. archive and compression ergonomics |
| 50 | | -6. platform helpers like clipboard, "open with default app", temp files, and app-state persistence |
| 51 | 60 | |
| 52 | 61 | These are the places where: |
| 53 | 62 | |
| 54 | 63 | - real apps need the functionality repeatedly |
| 55 | | -- the Fortran ecosystem has pieces, but not yet an obvious default |
| 64 | +- the Fortran ecosystem still lacks an obvious default |
| 56 | 65 | - your own codebase already contains extractable proof that the need is real |
| 57 | 66 | |
| 58 | 67 | ### Top Gaps |
| 59 | 68 | |
| 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. |
| 69 | +- File watching still looks like the single biggest remaining library hole: there are tools around the ecosystem, but no obvious reusable Fortran default that normal app authors would pull in. |
| 70 | +- Terminal mode handling and key decoding are still brittle, low-level, and repeatedly reinvented across interactive apps. |
| 71 | +- Expect-style PTY automation and process-test tooling remain unusually thin despite clear value for shells, TUIs, and CI. |
| 72 | +- Temp files, clipboard helpers, cache helpers, and app-state persistence are still mostly hand-rolled even though they are common practical needs. |
| 73 | +- Compression and archive support still exists mostly as bindings rather than as a small ergonomic package surface. |
| 74 | +- SQLite and local-data ergonomics remain promising, but they now look like a second-tier priority behind watch and interactive tooling. |
| 75 | + |
| 76 | +### Shipped First Wave |
| 77 | + |
| 78 | +These packages are no longer just candidates. They are shipped `v0.1.0` packages and form the current baseline of the library family. |
| 79 | + |
| 80 | +| Project | What It Covers | Repo | |
| 81 | +| --- | --- | --- | |
| 82 | +| `fgof-process` | argv-first subprocess helpers, capture, cwd and env overrides, timeouts | [fgof-process](https://github.com/FortranGoingOnForty/fgof-process) | |
| 83 | +| `fgof-fs` | paths, metadata, traversal, copy or move, lookup helpers | [fgof-fs](https://github.com/FortranGoingOnForty/fgof-fs) | |
| 84 | +| `fgof-pty` | PTY sessions, reads or writes, resize, lifecycle helpers | [fgof-pty](https://github.com/FortranGoingOnForty/fgof-pty) | |
| 85 | +| `fgof-lineedit` | line editing core, history, actions, completions, render snapshots | [fgof-lineedit](https://github.com/FortranGoingOnForty/fgof-lineedit) | |
| 66 | 86 | |
| 67 | | -### Strongest Bets Right Now |
| 87 | +### Strongest Remaining Bets Right Now |
| 68 | 88 | |
| 69 | | -These are the best "start here" candidates if the goal is maximum ecosystem value rather than novelty for its own sake. |
| 89 | +These are the best "start here next" candidates now that the first wave exists. |
| 70 | 90 | |
| 71 | 91 | Scores are `Impact / Gap severity / Feasibility / Local leverage / Maintenance burden`. Lower maintenance burden is better. |
| 72 | 92 | |
| 73 | 93 | | Project | Why It Stands Out | Existing Leverage | Scores | Verdict | |
| 74 | 94 | | --- | --- | --- | --- | --- | |
| 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 | 95 | | `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 | |
| 96 | +| `fgof-termios` | Terminal mode handling is still low-level and easy to get wrong; it would strengthen the interactive stack immediately | [fortsh system interface](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fortsh/src/system/interface.f90:1), `fit` keyboard handling | `4/4/5/5/2` | Strong candidate | |
| 80 | 97 | | `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 | |
| 98 | +| `fgof-expect` | PTY automation is valuable for interactive testing, demos, and CI, and the local leverage is strong | [fifftty PTY manager](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fifftty/src/pty_manager.f90:1), `fortsh` interactive YAML specs | `4/5/4/5/3` | Strong candidate | |
| 99 | +| `fgof-proc-test` | Process-fixture tooling would be useful immediately on top of `fgof-process` | [fortsh system interface](/Users/mfwolffe/GithubOrgs/FortranGoingOnForty/fortsh/src/system/interface.f90:1) and executor stack | `4/5/4/5/3` | Strong candidate | |
| 81 | 100 | | `fgof-clipboard` | Small, very practical, and clearly underpackaged | local clipboard code in `facsimile` | `4/5/4/4/3` | Strong candidate | |
| 82 | 101 | | `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 | 102 | | `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 | 103 | | `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 | 104 | | `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 | 105 | | `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 | 106 | |
| 89 | 107 | ### Crowded Or Lower-Priority Areas |
@@ -379,15 +397,15 @@ Example: |
| 379 | 397 | |
| 380 | 398 | ### Practical Sequencing |
| 381 | 399 | |
| 382 | | -If you decide to build from this document later, the most sensible first-wave sequence looks like: |
| 400 | +With the first wave already shipped, the most sensible next-wave sequence now looks like: |
| 383 | 401 | |
| 384 | | -1. `fgof-posix-core` |
| 385 | | -2. `fgof-fs` |
| 386 | | -3. `fgof-process` |
| 387 | | -4. `fgof-pty` |
| 388 | | -5. `fgof-lineedit` or `fgof-watch` |
| 402 | +1. `fgof-watch` |
| 403 | +2. `fgof-termios` |
| 404 | +3. `fgof-keys` |
| 405 | +4. `fgof-expect` or `fgof-proc-test` |
| 406 | +5. `fgof-temp` or `fgof-clipboard` |
| 389 | 407 | |
| 390 | | -That sequence maximizes reuse and minimizes duplicate low-level work. |
| 408 | +That sequence adds the most obvious missing value on top of what is already shipped without jumping too early into crowded territory. |
| 391 | 409 | |
| 392 | 410 | ## Local Extraction Evidence |
| 393 | 411 | |
