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.
- finalfinal-1.0.0/LICENSE +21 -0
- finalfinal-1.0.0/PKG-INFO +223 -0
- finalfinal-1.0.0/README.md +209 -0
- finalfinal-1.0.0/pyproject.toml +24 -0
- finalfinal-1.0.0/src/finalfinal/__init__.py +7 -0
- finalfinal-1.0.0/src/finalfinal/api.py +1006 -0
finalfinal-1.0.0/LICENSE
ADDED
|
@@ -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
|
+
|