Project
pydlock — A File-Encryption Package on PyPI
A one-command file-encryption tool and library on PyPI — password-derived keys, an authenticated cipher, and a versioned file format, carried through the full lifecycle of a published package.
Most of my code lives inside a larger system. pydlock was the opposite exercise: take one small job — encrypt and decrypt a file — and carry it through the full lifecycle of a real package, from a clean API to a CLI to a versioned release on PyPI.
Context
pydlock started as a 2020 utility — “padlock”, respelled with a py. The job is
modest: lock a file behind a password and unlock it later, aimed at someone who
wants to protect a file without learning a key-management tool. In 2026 I rebuilt
it as a package rather than a script.
The problem
A script and a package look similar and aren’t the same thing. A package needs a stable public surface, works as both an import and a tool, fails legibly, and is installable, versioned, and documented well enough that a stranger can use it without reading the source. That last part is where most personal projects quietly stop.
Approach
pydlock works two ways from one codebase:
- As a CLI —
pydlock lock <file>andpydlock unlock <file>, with the password read from an interactive prompt rather than a command-line argument. - As a library — import it and call
lock()/unlock()on a file.
Under both, the same pipeline: derive a key from the password with salted scrypt, encrypt with Fernet (AES-128-CBC with an HMAC-SHA256 authentication tag), and write the result inside a versioned file envelope. The version field is what lets the 2026 build still read and decrypt files written by the original 2020 one.
Around that it carries the scaffolding of a published package: packaging metadata, a test suite, a changelog, and a release on the Python Package Index cut through tokenless OIDC publishing.
Outcome
pydlock is live on PyPI under the MIT
license — pip install pydlock and it’s there, CLI and library both.