DEV Community: Danilo Fortunato

The distribution checklist nobody writes down

Danilo Fortunato — Sat, 10 Oct 2026 07:09:48 +0000

I ship four small Python CLI tools. Not libraries — command-line utilities you install and run once. And I learned the hard way that building them is the easy part. The part with all the friction is putting them where someone who needs them will actually find them.

This is the checklist I wish I had, with the exact walls I hit. No theory.

1. PyPI name squatting is the first wall

My website auditor is called SiteAuditor. The PyPI name site-auditor was already taken by an unrelated project. So the distribution name and the command name had to be split:

package:  danyblitz-site-auditor
command:  siteauditor

Two lessons:

Check the name before you fall in love with it. pip index versions <name> or the PyPI JSON API tells you in one second whether it is free.
Decide the package name and the console-script name separately. You are not forced to make them agree.

And drop the dash in the command name. photo-metaclean as a package, photometaclean as the command. A dash in a command name is friction in every doc, every alias, every shell one-liner.

2. winget needs a real release asset, not a source zip

winget installs from a URL plus a SHA256. If your GitHub release has no .exe, you cannot ship a winget package at all. The manifest is a portable one, schema 1.6.0.

Two frictions worth knowing before you start:

A one-time Microsoft CLA. The bot asks the account to reply @microsoft-github-policy-service agree. It is a checkbox, but nothing moves until it is done.
The review queue. Free, human, and unschedulable. Set expectations.

3. Directories are a queue, not a launch

SaaSHub, AlternativeTo and friends: submission is free, review is slow, and it is a queue shared with everyone else. Some offer a paid "priority review"; the free path is fine if you stop expecting same-day visibility.

The field that actually matters is alternatives. A tool with no alternatives listed is nearly invisible. Add two or three real ones and you show up where people compare tools by function.

4. The boring thing that mattered most

The highest-leverage step was the least exciting: getting the tools into the package managers. A tool that is pip install <name> away is discoverable in a way a landing page is not. My landing pages were fine for months and nobody came. The moment the packages were installable, the problem changed from "marketing" to "is the name right".

The one-line version

Publication is not discovery. A landing page pushes; it does not pull. Discovery lives in two places only:

package managers (PyPI, winget, npm, Homebrew)
directories where someone searches by what a tool does

Everything else — Product Hunt, a dev.to post, a tweet — is a one-day spike on top of that base.

If you want to see a finished tool of this kind: SiteAuditor audits a page and its links, Photo MetaClean strips EXIF, and both are pip install away.

I ran my own website auditor on my own landing page. It gave me 89/100, and three of the five findings are noise

Danilo Fortunato — Tue, 06 Oct 2026 06:42:27 +0000

I ran my own website auditor on my own landing page. That is the only honest test a linter-like tool has: either it finds things you would rather it had not, or it is too generous to be trusted.

Here is what it gave me.

  SiteAudit Report
  https://danyblitz-bit.github.io/site-auditor/

  Score: 89/100 (Grade B)
  Status: 200  |  Time: 524ms  |  Size: 5 KB

Five warnings came back:

!  Title too long (67 chars)
!  Meta description too long (168 chars)
!  Missing Open Graph tags: og:title, og:description, og:image
!  No canonical link
!  Missing Content-Security-Policy header

Five findings, five equal markers, one score. The problem is that they are not equal.

Three of these are noise on this page

Title too long (67 chars). Google renders roughly 580px of it, which lands around 60 characters. So it will be truncated. Truncated is not broken — it still ranks, it still reads, it just gets cut. A real finding with a severity of almost nothing.

Meta description too long (168 chars). Same story, cut around 155. The meta description does not affect ranking at all; it affects whether someone clicks. Losing the last 13 characters of a 168-character description changes nothing measurable.

No canonical link. A canonical exists to tell search engines which of several duplicates is the real one. This is a single static page with one URL, served from GitHub Pages. There is no duplicate to point away from. The rule my own tool enforces is a rule that resolves a problem this page cannot have.

Two of them are not noise

Missing Open Graph tags. This is the one that actually bites, and it bites at the exact moment the product is being shared. When someone drops the link into Product Hunt, Slack, Twitter or a message, the preview falls back to whatever it can scrape: a title and, if you are lucky, an image. On a link you spent a week preparing, the preview is half the impression. This one is not a style point.

Missing Content-Security-Policy. The header is a real defence, not a metadata nicety: without it, a stray script that ends up on the page can run and exfiltrate. For a static one-page site with zero JavaScript, the practical risk is near zero — which is precisely why a score is the wrong instrument here. The same warning would be the most important line in the output for a page that logs users in.

What a single number cannot express

That is the part worth stealing from this. A score compresses twenty signals into one integer, and weighting is the only thing that separates an audit from a checklist. A report that flags five items as ! and tells you nothing about which of them is worth an hour of your time has handed you a todo list, not an opinion.

The fix is not a cleverer formula — weights are context-dependent and anyone who hardcodes "canonical: 10 points" is guessing. The fix is that anything you automate for an end user has to end with a ranking and a reason, or the user has to do the ranking themselves, which is the work they were trying to avoid.

In my case the honest answer for this page is: add the three Open Graph tags, add a CSP because it is one line, shorten the title because it is one edit, and ignore the other two.

Which is exactly five findings reduced to one opinion. The tool's job was to produce the list. Producing the opinion is still mine.

Stripping EXIF at the byte level: no re-encoding, no quality loss

Danilo Fortunato — Thu, 01 Oct 2026 18:12:13 +0000

The tool everyone's using is quietly damaging your photos

If you strip metadata from an image, the usual approach is to decode it, delete the fields, and encode it again. That is the natural way to do it, because every image library exposes exactly that: a decode step, a field dictionary, an encode step.

The problem is that JPEG is a lossy format, and the encoder you use is not the encoder that made the file. So a round trip through Pillow changes the bytes of the image data itself, not just the metadata:

from PIL import Image

im = Image.open("photo.jpg")
clean = Image.new(im.mode, im.size)     # a fresh, empty image
clean.putdata(list(im.getdata()))        # copy every pixel
clean.save("clean.jpg", quality=95)      # re-encode at a quality you invented

You now have a file that is not your original. It is a lossy re-compression of your original, and the damage is not recoverable. The quality=95 is not a neutral default — it is a lossy re-compression of your original. If your original was quality=88, you just paid twice.

Stripping metadata should not change the picture. It is a container edit, not an image edit.

JPEG is a sequence of segments, and only some of them are the image

A JPEG file is a stream of markers. Each is FF xx, followed by a 2-byte big-endian length, followed by payload. The pixel data lives in exactly one of them: SOS (start of scan). Everything before SOS is metadata containers, and everything from SOS to FF D9 (EOI) is the compressed scan data.

That means the whole operation is: copy the bytes, skip the segments you do not want.

import struct

# APPn = the metadata containers; APP0 is JFIF, APP1 is where Exif/XMP live
DROP = {0xE1} | set(range(0xE2, 0xF0))


def strip_jpeg_metadata(data: bytes) -> bytes:
    out = bytearray(data[:2])          # SOI
    i = 2
    while i < len(data) - 1:
        if data[i] != 0xFF:
            # we are inside the entropy-coded scan: copy the rest verbatim
            out += data[i:]
            break
        marker = data[i + 1]
        if marker == 0xDA:             # SOS: the image itself starts here
            out += data[i:]
            break
        if marker == 0xD9:             # EOI
            out += data[i:]
            break
        seg_len = struct.unpack(">H", data[i + 2 : i + 4])[0]
        end = i + 2 + seg_len
        if marker not in DROP:
            out += data[i:end]
        i = end
    return bytes(out)

Two properties fall out of this for free:

The scan data is never touched, so there is no quality loss. Not "low loss" — none. The compressed bytes are the same bytes.
It cannot leave a partial segment behind, because lengths are read from the file rather than guessed.

PNG needs a different, simpler rule

PNG is chunks, not segments: an 8-byte length, a 4-byte type, the payload, a 4-byte CRC. Metadata lives in the ancillary chunks tEXt, zTXt, iTXt and eXIf. The critical chunks (IHDR, PLTE, IDAT, IEND) and the ancillary ones that affect rendering (tRNS, gAMA, cHRM) must stay.

import struct

PNG_DROP = {b"tEXt", b"zTXt", b"iTXt", b"eXIf"}


def iter_png_chunks(data: bytes):
    pos = 8                                   # skip the PNG signature
    while pos < len(data):
        (length,) = struct.unpack(">I", data[pos : pos + 4])
        ctype = data[pos + 4 : pos + 8]
        total = 12 + length                   # len + type + data + crc
        yield ctype, data[pos : pos + total]
        pos += total


def strip_png_metadata(data: bytes) -> bytes:
    out = bytearray(data[:8])
    for ctype, chunk in iter_png_chunks(data):
        if ctype not in PNG_DROP:
            out += chunk
    return bytes(out)

Because every chunk carries its own CRC, dropping whole chunks keeps the file valid — there is no checksum to recompute.

The part that matters: assert it, do not hope

A metadata stripper that silently fails is worse than none, because you believe you are covered. The cheapest possible insurance is a self-check that builds a file known to contain the data, strips it, and asserts nothing survives:

import io, sys
from PIL import Image, TiffImagePlugin

def make_jpeg_with_exif() -> bytes:
    # a real 64x64 JPEG carrying a genuine GPS block, written by PIL so the
    # fixture is a file any image library can actually open
    im = Image.new("RGB", (64, 64), (40, 90, 160))
    exif = im.getexif()
    gps = exif.get_ifd(0x8825)
    gps[1] = "N"
    gps[2] = (TiffImagePlugin.IFDRational(48, 1), TiffImagePlugin.IFDRational(51, 1), TiffImagePlugin.IFDRational(2952, 100))
    gps[3] = "E"
    gps[4] = (TiffImagePlugin.IFDRational(2, 1), TiffImagePlugin.IFDRational(17, 1), TiffImagePlugin.IFDRational(4024, 100))
    buf = io.BytesIO()
    im.save(buf, format="JPEG", quality=90, exif=exif)
    return buf.getvalue()

def jpeg_scan_data(buf: bytes) -> bytes:
    """The compressed image itself: from the start-of-scan marker to the end."""
    i = buf.find(b"\xff\xda")
    assert i != -1, "no SOS marker, the fixture is not a JPEG we understand"
    return buf[i:]

def main() -> int:
    raw = make_jpeg_with_exif()
    # the fixture must really contain the data, or the test proves nothing
    assert Image.open(io.BytesIO(raw)).getexif().get_ifd(0x8825), "fixture is wrong"
    clean = strip_jpeg_metadata(raw)
    # and the stripper must really remove it
    assert not Image.open(io.BytesIO(clean)).getexif().get_ifd(0x8825), "GPS survived"
    assert len(clean) < len(raw)
    # the image data must be byte-identical, not merely the same size
    assert jpeg_scan_data(clean) == jpeg_scan_data(raw), "pixels were re-encoded"
    print("self-check OK: EXIF/GPS stripped, pixels preserved")
    return 0

if __name__ == "__main__":
    sys.exit(main())

Both halves have to be asserted. "The metadata is gone" is the easy claim; "the image data is byte-identical" is the claim that actually matters, and it is the one that is normally never checked.

Where this lives

I packaged this as Photo MetaClean — standard library only, no dependencies, offline by design, MIT licensed:

Windows binary: danyblitz.gumroad.com/l/photo-metaclean (8 MB, single file, no installer)
Source: github.com/danyblitz-bit/photo-metaclean

The same byte-level treatment for documents is in PDF MetaClean, and the landing page is here.

What to check on your own photos

Run any of these on a file before you upload it anywhere:

exiftool photo.jpg
strings photo.jpg | head -40

If you see a GPS block, a camera serial number, your name, or an original filename, it is in the file. Social platforms strip some of it; not all of it, not consistently, and not for every upload path. The part you control is the file you hand over.

One caveat worth being honest about

Byte-level copying means the tool does not rewrite anything it does not understand. That is a feature for your image data and a limitation for thumbnails, colour profiles or ICC data you may want to keep. Decide per file: a public upload and a print-ready master have different requirements, and the safe default is to strip for the upload and keep the master untouched.

Try it

Photo MetaClean launched on Product Hunt on 2 October 2026. The single-file
Windows binary is on GitHub Releases:

v1.1.0 keeps EXIF Orientation instead of dropping it along with the rest of
APP1, which is what you would have hit on any phone photo.

If you downloaded v1.0.0, that build drops Orientation as well, so a phone
photo comes out sideways. There is no auto-update: the executable makes no
network connection at all, so nothing will ever tell you a new version exists.
You have to come back for it.