📖 FSync
This tool eliminates the problem of scattered libraries by synchronizing 🔄 selected files spread across different projects on your machine (locally). No more chaos and manual file copying.
At first glance, centralizing libraries seems like a great idea. It makes work easier and avoids code duplication. In practice, however, some complications arise:
- You don't always want to update a library in a project you're no longer developing, but it still needs to work.
- Some libraries must be part of the repository. When you hand off/close a project, you want everything in one place, without having to pull additional dependencies from external sources.
- It's better when all resources are in the project directory. It simplifies configuration (Makefile, CMake), eliminates path and version issues, and improves IDE integration.
This solution is perfect if you run many smaller projects and care about efficient library management (code that appears across multiple projects). If you make frequent changes, want to avoid messy code, but don't have time to spend hours organizing dependencies: this tool is for you! The program is dead simple. What matters is efficient and effective work, without unnecessary bureaucracy. The open source community can do its thing, but here the priority is a happy client and a working project done ⚡fast and 👍good enough.
🧐 Problems!
- ❌ Possible accidental overwrites: if you edit two versions of a library at the same time.
- ✅ Avoid this, but if it happens, every overwritten version is saved as a timestamped backup, so you can always recover your changes.
- ❌ No environment isolation: different projects may require different versions of the same library.
- ✅ Not a problem! Just create separate entries for different versions, keeping synchronization independent. You can also comment out entries for libraries that shouldn't be updated anymore.
- ❌ Code duplication across repositories: instead of one library copy, you have several in different projects.
- ✅ That's the point! Each client should have their own library version, with no dependencies on other repos. Full control, zero unnecessary complications.
🤔 Alternatives?
Of course you can approach this more professionally by:
- Versioning libraries as separate projects/repositories and updating them as needed.
- Using Git Submodules, which allows tracking library versions in the repository.
- External package managers (
pip,npm,cargo) that simplify dependency management.
If any of our libraries reach a stable version that we don't chaotically change every project, and they're good enough, it's worth considering one of the above solutions.
⚙️ Config
The sync.json file defines file synchronization configuration. Each entry is a key (filename) and a list of paths to synchronize. Keys starting with # are treated as commented out and skipped.
Paths can use shorthand notation via the dict.ini file, which defines aliases for frequently repeated locations. In sync.json paths you can reference these aliases using {key} notation.
Example
Running the program with the -e, --example flag will create example config files locally.
File dict.ini
web = C:/Users/Me/Projects/WebPage/backend
staff = C:/Users/Me/Desktop/MyStaff/test
work = C:/Users/Me/Work/Drivers/repos
File sync.json
{
"serial.c": ["{staff}/serial.c", "{work}/PLC/serial_port.c"],
"utils.py": ["{web}/lib/utils.py", "{work}/PLC/misc.py"],
"#old_lib.c": ["{staff}/old_lib.c", "{work}/legacy/old_lib.c"]
}
📦 Install
pip install fsync # basic
pip install fsync[diff] # + rich (diff display)
Also available as standalone
.exeon GitHub Releases.
🚀 Use
First, set the workspace: the directory containing your config files (sync.json, dict.ini) and where backups will be stored:
pyfsync -w C:/Projects/sync # specified path
pyfsync -w # current directory
Running the program generates a report:
pyfsync
To synchronize (i.e. update older file versions), just add the -u, --update flag:
pyfsync -u
For each pair of files with discrepancies, tags are generated. You can use them to inspect differences between files with the -d, --diff flag:
pyfsync -d 1.1
Metadata
Release files for fsync 1.1.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| fsync-1.1.1.tar.gz | 10.9 kB | With provenance | Details for fsync-1.1.1.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| fsync-1.1.1-py3-none-any.whl | Python 3 | none | any | Details for fsync-1.1.1-py3-none-any.whl |
Total release size: 22.0 kB
Release files / fsync-1.1.1.tar.gz
| Download URL | fsync-1.1.1.tar.gz |
|---|---|
| Size | 10.9 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
b706508d0e7ca41fa87f7df21628b3cddc78e80f8abff3ef77d85557cda12abb
|
|
BLAKE2b-256 checksum How to use checksums |
864bb251732b0e5fb51aae7134fa8e090285a8a67de9f203af7973942fad82b7
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 27, 2026.
Transparency logRelease files / fsync-1.1.1-py3-none-any.whl
| Download URL | fsync-1.1.1-py3-none-any.whl |
|---|---|
| Size | 11.1 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
3bc77bede1dc237515acda18f9ac899ea97eeb5d16e8c3178cd002883b0d062c
|
|
BLAKE2b-256 checksum How to use checksums |
b4ae4574dab5bf5ce1b387a5209260471c06e84f4652a063f06d17ca034e4550
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 27, 2026.
Transparency logSecurity for fsync 1.1.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for fsync-1.1.1.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Jul 27, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.