Skip to main content

📖 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 .exe on 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)

Source distribution for fsync 1.1.1
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)

Table of built distributions (wheels) for fsync 1.1.1
File Interpreter ABI Platform Actions
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 log

Release 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 log

Security 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.

Select from 2 files

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 log

A 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.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page