finalfinal 1.0.0__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,21 @@
1
+ MIT License
2
+
3
+ Copyright (c) 2026 Tristan Languebien
4
+
5
+ Permission is hereby granted, free of charge, to any person obtaining a copy
6
+ of this software and associated documentation files (the "Software"), to deal
7
+ in the Software without restriction, including without limitation the rights
8
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
+ copies of the Software, and to permit persons to whom the Software is
10
+ furnished to do so, subject to the following conditions:
11
+
12
+ The above copyright notice and this permission notice shall be included in all
13
+ copies or substantial portions of the Software.
14
+
15
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
+ SOFTWARE.
@@ -0,0 +1,223 @@
1
+ Metadata-Version: 2.4
2
+ Name: finalfinal
3
+ Version: 1.0.0
4
+ Summary: FinalFinal™ is a file versioning system that encodes the project history directly into the filename, where it obviously belongs.
5
+ Keywords: filesystem,version control
6
+ Author: tlanguebien
7
+ Author-email: tlanguebien <tlanguebien@gmail.com>
8
+ License-Expression: MIT
9
+ License-File: LICENSE
10
+ Requires-Dist: reportlab
11
+ Requires-Python: >=3.9
12
+ Project-URL: Homepage, https://github.com/tristanlanguebien/finalfinal
13
+ Description-Content-Type: text/markdown
14
+
15
+ # FinalFinal™
16
+ ### *Where Done Is Just Another Iteration.*
17
+
18
+ **FinalFinal™** is a file versioning system that encodes the project history directly into the filename, where it obviously belongs.
19
+ No Git, no SVN: **The filename is the changelog.**
20
+
21
+ ## Use Case
22
+
23
+ In the age of deliverable-oriented agility, versioning alone is no longer enough. You need to *tell a story*. With FinalFinal™, every file becomes a compressed roadmap, a monument to the iterative process:
24
+
25
+ ```
26
+ myfile_NEW_forProducers_minor-editsV2_FINAL-MostlyApproved.pdf
27
+ ```
28
+
29
+ Each suffix is a chapter:
30
+
31
+ | Suffix | What it communicates |
32
+ |---|---|
33
+ | `NEW` | Ambition and optimism |
34
+ | `forProducers` | Illusion of governance |
35
+ | `minor-editsV2` | Resilience in the face of client feedback |
36
+ | `FINAL` | The conclusion of a production cycle (Provisional) |
37
+ | `MostlyApproved` | Aknowledges endless possibilities |
38
+
39
+ Every additional suffix reinforces collective confidence. If you have reached `final-v3-def-ok2`, you know the project is moving forward.
40
+
41
+ ## Features
42
+
43
+ ### Context-Driven Incrementation
44
+
45
+ `wip`, `retake`, `fix`, `done`, and `final` are handled as distinct increment types, each drawing from a curated pool of suffixes. FinalFinal™ helps you write the perfect narrative for your file, one version at a time.
46
+
47
+ ### Certainty Levels
48
+
49
+ Are you unsure about your changes? Quietly confident? Dangerously overcommitted? FinalFinal™'s collection of carefully engineered affixes lets you compose version names with genuine emotional nuance:
50
+
51
+ - Low certainty: `report_probably-fixed.docx`, `brief sortOfDone.pdf`
52
+ - High certainty: `contract_100%_DEFINITIVE.docx`
53
+
54
+ ### Reset
55
+
56
+ At some point, your filename will be ungodly long. This is not a flaw, just a sign that the project has lived.
57
+
58
+ The `reset` feature archives everything into a tidy `_OLD` folder (or `BEFORE_THE_INCIDENT`, if you prefer) and starts you fresh with one of our curated restart suffixes. You may then begin making the same mistakes again.
59
+
60
+ ### PDF Export
61
+
62
+ At some point, someone will ask for a changelog. `to_pdf` generates a professional PDF documenting every version of your file, sorted by filename length (the closest available proxy for chronological order), annotated with modification descriptions such as:
63
+
64
+ > *"At 2024-11-04 at 14:32:17, someone clicked Save. We'll count that as work."*
65
+
66
+ Send it by email. Your inbox becomes your audit trail. This is fine.
67
+
68
+ ## Technical Architecture
69
+
70
+ FinalFinal™ is powered by our proprietary **Recursive Semantic Drift™** engine, which enables:
71
+
72
+ - **Unlimited suffix stacking**: no enforced ceiling = endless possibilities.
73
+ - **Emotional and certitude encoding**: affixes such as `maybe`, `definitely`, `god-knows`, and `not-my-problem-anymore` allow for nuanced sentiment to be embedded directly in the file path.
74
+ - **Multiple coexisting final versions**: because sometimes the client validates two things on the same afternoon.
75
+
76
+ ### Compatibility
77
+
78
+ FinalFinal™ is fully compatible with all modern file distribution infrastructure:
79
+
80
+ - 📧 Email (recommended)
81
+ - 💾 USB drives
82
+ - ☁️ Google Drive
83
+ - 🗂️ Network Shares named `\\PROD-FINAL\FINAL`
84
+
85
+ ## Security & Compliance
86
+
87
+ FinalFinal™ is compliant with the following standards:
88
+
89
+ - **ISO-Good-Enough** (validated by nobody in particular)
90
+ - **Internally Ratified in a Meeting** (see the invite calendar for proof)
91
+ - **I.W.O.M.C.** (It Works On My Computer, the gold standard of pre-delivery testing)
92
+
93
+ > [!CAUTION]
94
+ > FinalFinal™ does not implement access control, version locking, encryption, or conflict resolution. These are considered premium concerns for a future definitive edition of FinalFinal™.
95
+
96
+ ## Client Testimonials
97
+
98
+ > *"Since adopting `Budget_2025_v4_final_FINAL_ok2_USETHIS.xlsx`, we have reduced version conflicts by 0% but our perceived strategic alignment has increased by 300%."*
99
+ >
100
+ > -- A multinational corporation
101
+
102
+
103
+ > *"We spent a long time choosing between Git and FinalFinal™. What ultimately convinced us to go with FinalFinal™ was the price."*
104
+ >
105
+ > -- A cash-strapped CEO
106
+
107
+ > *"Before FinalFinal™, I wasn't versioning my files at all. Now I am. Sometimes I wonder if things were better before."*
108
+ >
109
+ > -- A weekend entrepreneur
110
+
111
+
112
+ ## Roadmap
113
+
114
+ - **PowerPoint changelog export**: Following the overwhelming success of the PDF exporter and numerous requests from the field, our team is working tirelessly to deliver changelog exports in `.pptx` format. This will allow version history to be presented to the team with full slide transitions.
115
+
116
+ - **Variations**: The introduction of a branching concept. Functionally similar to Git branches, but implemented via subfolders for a better user experience.
117
+
118
+
119
+ ## FAQ
120
+
121
+ **Why doesn't FinalFinal™ use commit messages?**
122
+
123
+ The name speaks for itself. For additional detail, send the file by email to your colleagues or clients. Your inbox *becomes* your changelog. By CC-ing the entire team on each send, you can be confident that everyone is up to date.
124
+
125
+ **Why can't I use `increment()` on a file that hasn't gone through `track()` first?**
126
+
127
+ On any given project, it would be unreasonable to version *every* file. Test files, throwaway scripts, files you are absolutely certain are already in their definitive final form from the first attempt: these do not require tracking.
128
+
129
+ **What if two people modify the file at the same time?**
130
+
131
+ This is called a *collaborative version event*. Both versions are valid. The longer filename wins.
132
+
133
+
134
+ ## Installation & Deployment
135
+
136
+ Download the source code and unzip into your project directory. FinalFinal is supported by all modern deployment systems (dropbox, google drive, wetransfer...)
137
+
138
+ Alternatively, you can use pip or uv, even if it isn't frankly the spirit of the thing.
139
+
140
+ ```bash
141
+ uv add finalfinal
142
+ pip install finalfinal
143
+ ```
144
+
145
+ ## Quick Start
146
+
147
+ The first step is to track the file.
148
+
149
+ > [!WARNING]
150
+ > When tracking a file, a metadata file ``important_notes_DONT_DELETE.docx`` will be created.
151
+ > Do not ask for a more robust system: we already wrote DONT_DELETE in uppercase, YOU are responsible if the versioning framework breaks.
152
+
153
+ ```bash
154
+ finalfinal --path brief.txt --track
155
+ >>> "brief START.txt"
156
+ ```
157
+
158
+ Once the file is tracked, you can start using the increment feature.
159
+
160
+ ```bash
161
+ finalfinal --path brief.txt --increment
162
+ >>> "brief START-updated.txt"
163
+ ```
164
+
165
+ You can adjust the suffix by providing an `increment_type`, and nuance emotional feedback thanks to the `certainty_level` option.
166
+
167
+ ```bash
168
+ # Available increment types are: wip, done, retake, fix, final. Defaults to wip
169
+ finalfinal --path brief.txt --increment --increment_type done --certainty_level 0
170
+ >>> "brief START-updated-Not_Far_From_Decent.txt"
171
+ ```
172
+
173
+ The default certainty level is 1. Below 1 means "unsure", above 1 means "reckless confidence".
174
+
175
+ ```bash
176
+ finalfinal --path brief.txt --increment --increment_type final --certainty_level 99
177
+ >>> "brief START-updated-Not_Far_From_Decent-ABSOLUTELYDEFINITIVE.txt"
178
+ ```
179
+
180
+ Keep everyone up to date thanks to the PDF Export feature.
181
+
182
+ ```bash
183
+ finalfinal --path brief.txt --export_pdf
184
+ >>> "brief_changelog.pdf"
185
+ ```
186
+
187
+ > FinalFinal™ Changelog
188
+ > File: brief.txt
189
+ > Generated: 2026-06-14 at 11:48:08
190
+ > The following represents the complete audit trail of this file. It should not be used in a court of law.
191
+ >
192
+ > Version 1: brief START.txt
193
+ > A human being interacted with this file on 2026-06-14 at 11:36:34. Motivation: unknown.
194
+ >
195
+ > Version 2: brief START-updated.txt
196
+ > This version exists because someone, somewhere, was not satisfied with the previous one.
197
+ >
198
+ > Version 3: brief START-updated-Not_Far_From_Decent.txt
199
+ > The file was improved, allegedly, on 2026-06-14 at 11:46:36.
200
+ >
201
+ > Version 4: brief START-updated-Not_Far_From_Decent-ABSOLUTELYDEFINITIVE.txt
202
+ > Edits were performed. Whether they were improvements is a matter of perspective.
203
+
204
+ When the filename has grown to a length that violates several international conventions, it is time to reset (the metadata file is preserved. It has seen too much to be discarded.)
205
+
206
+ ```bash
207
+ finalfinal --path brief.txt --reset
208
+ >>> brief-NEW_LEAF.txt
209
+ ```
210
+
211
+ ## Contributing
212
+
213
+ Send me your ideas on Discord, i'll consider implementing them.
214
+
215
+ ---
216
+
217
+ <div align="center">
218
+
219
+ **FinalFinal™** - *Because the alternative is learning to use a real version control system.*
220
+
221
+ *© FinalFinal™ Industries. All versions reserved. None of them final.*
222
+
223
+ </div>
@@ -0,0 +1,209 @@
1
+ # FinalFinal™
2
+ ### *Where Done Is Just Another Iteration.*
3
+
4
+ **FinalFinal™** is a file versioning system that encodes the project history directly into the filename, where it obviously belongs.
5
+ No Git, no SVN: **The filename is the changelog.**
6
+
7
+ ## Use Case
8
+
9
+ In the age of deliverable-oriented agility, versioning alone is no longer enough. You need to *tell a story*. With FinalFinal™, every file becomes a compressed roadmap, a monument to the iterative process:
10
+
11
+ ```
12
+ myfile_NEW_forProducers_minor-editsV2_FINAL-MostlyApproved.pdf
13
+ ```
14
+
15
+ Each suffix is a chapter:
16
+
17
+ | Suffix | What it communicates |
18
+ |---|---|
19
+ | `NEW` | Ambition and optimism |
20
+ | `forProducers` | Illusion of governance |
21
+ | `minor-editsV2` | Resilience in the face of client feedback |
22
+ | `FINAL` | The conclusion of a production cycle (Provisional) |
23
+ | `MostlyApproved` | Aknowledges endless possibilities |
24
+
25
+ Every additional suffix reinforces collective confidence. If you have reached `final-v3-def-ok2`, you know the project is moving forward.
26
+
27
+ ## Features
28
+
29
+ ### Context-Driven Incrementation
30
+
31
+ `wip`, `retake`, `fix`, `done`, and `final` are handled as distinct increment types, each drawing from a curated pool of suffixes. FinalFinal™ helps you write the perfect narrative for your file, one version at a time.
32
+
33
+ ### Certainty Levels
34
+
35
+ Are you unsure about your changes? Quietly confident? Dangerously overcommitted? FinalFinal™'s collection of carefully engineered affixes lets you compose version names with genuine emotional nuance:
36
+
37
+ - Low certainty: `report_probably-fixed.docx`, `brief sortOfDone.pdf`
38
+ - High certainty: `contract_100%_DEFINITIVE.docx`
39
+
40
+ ### Reset
41
+
42
+ At some point, your filename will be ungodly long. This is not a flaw, just a sign that the project has lived.
43
+
44
+ The `reset` feature archives everything into a tidy `_OLD` folder (or `BEFORE_THE_INCIDENT`, if you prefer) and starts you fresh with one of our curated restart suffixes. You may then begin making the same mistakes again.
45
+
46
+ ### PDF Export
47
+
48
+ At some point, someone will ask for a changelog. `to_pdf` generates a professional PDF documenting every version of your file, sorted by filename length (the closest available proxy for chronological order), annotated with modification descriptions such as:
49
+
50
+ > *"At 2024-11-04 at 14:32:17, someone clicked Save. We'll count that as work."*
51
+
52
+ Send it by email. Your inbox becomes your audit trail. This is fine.
53
+
54
+ ## Technical Architecture
55
+
56
+ FinalFinal™ is powered by our proprietary **Recursive Semantic Drift™** engine, which enables:
57
+
58
+ - **Unlimited suffix stacking**: no enforced ceiling = endless possibilities.
59
+ - **Emotional and certitude encoding**: affixes such as `maybe`, `definitely`, `god-knows`, and `not-my-problem-anymore` allow for nuanced sentiment to be embedded directly in the file path.
60
+ - **Multiple coexisting final versions**: because sometimes the client validates two things on the same afternoon.
61
+
62
+ ### Compatibility
63
+
64
+ FinalFinal™ is fully compatible with all modern file distribution infrastructure:
65
+
66
+ - 📧 Email (recommended)
67
+ - 💾 USB drives
68
+ - ☁️ Google Drive
69
+ - 🗂️ Network Shares named `\\PROD-FINAL\FINAL`
70
+
71
+ ## Security & Compliance
72
+
73
+ FinalFinal™ is compliant with the following standards:
74
+
75
+ - **ISO-Good-Enough** (validated by nobody in particular)
76
+ - **Internally Ratified in a Meeting** (see the invite calendar for proof)
77
+ - **I.W.O.M.C.** (It Works On My Computer, the gold standard of pre-delivery testing)
78
+
79
+ > [!CAUTION]
80
+ > FinalFinal™ does not implement access control, version locking, encryption, or conflict resolution. These are considered premium concerns for a future definitive edition of FinalFinal™.
81
+
82
+ ## Client Testimonials
83
+
84
+ > *"Since adopting `Budget_2025_v4_final_FINAL_ok2_USETHIS.xlsx`, we have reduced version conflicts by 0% but our perceived strategic alignment has increased by 300%."*
85
+ >
86
+ > -- A multinational corporation
87
+
88
+
89
+ > *"We spent a long time choosing between Git and FinalFinal™. What ultimately convinced us to go with FinalFinal™ was the price."*
90
+ >
91
+ > -- A cash-strapped CEO
92
+
93
+ > *"Before FinalFinal™, I wasn't versioning my files at all. Now I am. Sometimes I wonder if things were better before."*
94
+ >
95
+ > -- A weekend entrepreneur
96
+
97
+
98
+ ## Roadmap
99
+
100
+ - **PowerPoint changelog export**: Following the overwhelming success of the PDF exporter and numerous requests from the field, our team is working tirelessly to deliver changelog exports in `.pptx` format. This will allow version history to be presented to the team with full slide transitions.
101
+
102
+ - **Variations**: The introduction of a branching concept. Functionally similar to Git branches, but implemented via subfolders for a better user experience.
103
+
104
+
105
+ ## FAQ
106
+
107
+ **Why doesn't FinalFinal™ use commit messages?**
108
+
109
+ The name speaks for itself. For additional detail, send the file by email to your colleagues or clients. Your inbox *becomes* your changelog. By CC-ing the entire team on each send, you can be confident that everyone is up to date.
110
+
111
+ **Why can't I use `increment()` on a file that hasn't gone through `track()` first?**
112
+
113
+ On any given project, it would be unreasonable to version *every* file. Test files, throwaway scripts, files you are absolutely certain are already in their definitive final form from the first attempt: these do not require tracking.
114
+
115
+ **What if two people modify the file at the same time?**
116
+
117
+ This is called a *collaborative version event*. Both versions are valid. The longer filename wins.
118
+
119
+
120
+ ## Installation & Deployment
121
+
122
+ Download the source code and unzip into your project directory. FinalFinal is supported by all modern deployment systems (dropbox, google drive, wetransfer...)
123
+
124
+ Alternatively, you can use pip or uv, even if it isn't frankly the spirit of the thing.
125
+
126
+ ```bash
127
+ uv add finalfinal
128
+ pip install finalfinal
129
+ ```
130
+
131
+ ## Quick Start
132
+
133
+ The first step is to track the file.
134
+
135
+ > [!WARNING]
136
+ > When tracking a file, a metadata file ``important_notes_DONT_DELETE.docx`` will be created.
137
+ > Do not ask for a more robust system: we already wrote DONT_DELETE in uppercase, YOU are responsible if the versioning framework breaks.
138
+
139
+ ```bash
140
+ finalfinal --path brief.txt --track
141
+ >>> "brief START.txt"
142
+ ```
143
+
144
+ Once the file is tracked, you can start using the increment feature.
145
+
146
+ ```bash
147
+ finalfinal --path brief.txt --increment
148
+ >>> "brief START-updated.txt"
149
+ ```
150
+
151
+ You can adjust the suffix by providing an `increment_type`, and nuance emotional feedback thanks to the `certainty_level` option.
152
+
153
+ ```bash
154
+ # Available increment types are: wip, done, retake, fix, final. Defaults to wip
155
+ finalfinal --path brief.txt --increment --increment_type done --certainty_level 0
156
+ >>> "brief START-updated-Not_Far_From_Decent.txt"
157
+ ```
158
+
159
+ The default certainty level is 1. Below 1 means "unsure", above 1 means "reckless confidence".
160
+
161
+ ```bash
162
+ finalfinal --path brief.txt --increment --increment_type final --certainty_level 99
163
+ >>> "brief START-updated-Not_Far_From_Decent-ABSOLUTELYDEFINITIVE.txt"
164
+ ```
165
+
166
+ Keep everyone up to date thanks to the PDF Export feature.
167
+
168
+ ```bash
169
+ finalfinal --path brief.txt --export_pdf
170
+ >>> "brief_changelog.pdf"
171
+ ```
172
+
173
+ > FinalFinal™ Changelog
174
+ > File: brief.txt
175
+ > Generated: 2026-06-14 at 11:48:08
176
+ > The following represents the complete audit trail of this file. It should not be used in a court of law.
177
+ >
178
+ > Version 1: brief START.txt
179
+ > A human being interacted with this file on 2026-06-14 at 11:36:34. Motivation: unknown.
180
+ >
181
+ > Version 2: brief START-updated.txt
182
+ > This version exists because someone, somewhere, was not satisfied with the previous one.
183
+ >
184
+ > Version 3: brief START-updated-Not_Far_From_Decent.txt
185
+ > The file was improved, allegedly, on 2026-06-14 at 11:46:36.
186
+ >
187
+ > Version 4: brief START-updated-Not_Far_From_Decent-ABSOLUTELYDEFINITIVE.txt
188
+ > Edits were performed. Whether they were improvements is a matter of perspective.
189
+
190
+ When the filename has grown to a length that violates several international conventions, it is time to reset (the metadata file is preserved. It has seen too much to be discarded.)
191
+
192
+ ```bash
193
+ finalfinal --path brief.txt --reset
194
+ >>> brief-NEW_LEAF.txt
195
+ ```
196
+
197
+ ## Contributing
198
+
199
+ Send me your ideas on Discord, i'll consider implementing them.
200
+
201
+ ---
202
+
203
+ <div align="center">
204
+
205
+ **FinalFinal™** - *Because the alternative is learning to use a real version control system.*
206
+
207
+ *© FinalFinal™ Industries. All versions reserved. None of them final.*
208
+
209
+ </div>
@@ -0,0 +1,24 @@
1
+ [project]
2
+ name = "finalfinal"
3
+ version = "1.0.0"
4
+ description = "FinalFinal™ is a file versioning system that encodes the project history directly into the filename, where it obviously belongs."
5
+ readme = "README.md"
6
+ authors = [
7
+ { name = "tlanguebien", email = "tlanguebien@gmail.com" }
8
+ ]
9
+ requires-python = ">=3.9"
10
+ dependencies = ["reportlab"]
11
+ license = "MIT"
12
+ license-files = ["LICENSE"]
13
+ keywords = ["filesystem", "version control"]
14
+
15
+ [project.urls]
16
+ Homepage = "https://github.com/tristanlanguebien/finalfinal"
17
+
18
+ [project.scripts]
19
+ finalfinal = "finalfinal:main"
20
+
21
+ [build-system]
22
+ requires = ["uv_build>=0.11.6,<0.12.0"]
23
+ build-backend = "uv_build"
24
+
@@ -0,0 +1,7 @@
1
+ from .api import IncrementType, _parse_args, increment, reset, to_pdf, track
2
+
3
+ __all__ = ["track", "increment", "reset", "to_pdf", "IncrementType"]
4
+
5
+
6
+ def main() -> None:
7
+ _parse_args()