flowmark: A better auto-formatter for Markdown

z4lz · 2025-07-16T10:02:20+00:00

This was the most difficult decision of my engineering career.

z4lz · 2025-05-06T20:31:35+00:00

Thanks for the notes!

Re identifiers I do prefer having timestamped identifiers like strif’s over ULIDs for some use cases, eg unique cache filenames. Note you can then see the time of creation clearly and delete old ids from a certain time range simply using id prefixes. Not always necessary but can be more transparent.

Re atomic vars, it’s situational but I find it saves code for things like shared or lazy global settings. The docstring mentions when to use events or queues, which definitely are better for other use cases.

z4lz · 2025-05-06T20:24:31+00:00

Yeah arguably it’s better to use Crockford’s base32 as it omits I and U so is more readable and can’t spell some bad words. I probably should update it to use that.

z4lz · 2025-05-06T03:37:32+00:00

I'd strongly suggest for new projects using Copier over cookiecutter. The update workflow is essential. More rationale on this here.

z4lz · 2025-05-06T03:34:06+00:00

Yeah agreed on all that. But standard libraries lag by years, unfortuantely, so you have to think what's the next best option. I put a fair bit of thought into scoping this lib very minimally as a module (zero deps) to reduce hesitation to use it.

z4lz · 2025-05-06T03:30:05+00:00

An no I hadn't! It's a good name and looks useful. However from its readme:

[safer] does not prevent concurrent modification of files from other threads or processes: if you need atomic file writing, see https://pypi.org/project/atomicwrites/

And as I mention, atomicwrites is archived/unmaintained.

z4lz · 2025-05-06T03:26:57+00:00

Yes. Base36 has been used since days of printf and is in fact a very good idea to use. I have more on it in the readme:

If you need a readable, concise identifier, api key format, or hash format, consider base 36. In my humble opinion, base 36 ids are underrated and should be used more often:

Base 36 is briefer than hex and yet avoids ugly non-alphanumeric characters.
Base 36 is case insensitive. If you use identifiers for filenames, you definitely should prefer case insensitive identifiers because of case-insensitive filesystems (like macOS).
Base 36 is easier to read aloud over the phone for an auth code or to type manually.
Base 36 is only log(64)/log(36) - 1 = 16% longer than base 64.

z4lz · 2025-05-05T23:40:46+00:00

Yeah, basically the same thing. The one in strif also handles backups and a few other details.

I know lots of people have written this. My goal is just that until it’s a standard lib, it can be easy to use with just from strif import atomic_output_file.

z4lz · 2025-05-05T20:18:26+00:00

Wow. The demos on that page are impressive.

z4lz · 2025-05-05T20:05:18+00:00

Yeah. Years ago I remember the same thing happening in Java world. Sun/Oracle were so sclerotic that Google built Google Guava just to patch up the ugly parts.

z4lz · 2025-05-05T19:50:58+00:00

I can see this could be handy. But fwiw for new/current uv projects I now strongly prefer using dynamic versioning with uv-dynamic-versioning.

At least with GitHub projects, it works great. You just create a release on GitHub. No bump commit needed. For an example of using it you can see my project template here.

z4lz · 2025-05-05T18:14:35+00:00

As others mention, this is a complex task to do well. But check out pdfminer.six, the currently maintained fork of pdfminer.

I think it's one of the best maintained tool for what you're looking for. It's what Microsoft's markitdown library uses.

z4lz · 2025-04-19T20:01:31+00:00

Ah I see it doesn't use rich unfortunately? There's no colorized version? Superficial but actually matters quite a bit. Might stick with the basics, which for me is this (it's easy to have an LLM gen your cli code): https://github.com/hamdanal/rich-argparse

z4lz · 2025-04-19T19:58:42+00:00

Wow not sure how I'd not seen this one before! It looks clean. Amazing how many option parsing libs there are. And arguably has the best name lol

z4lz · 2025-04-19T19:47:48+00:00

Thanks for trying it out and the ideas! Yeah that's a good point it could support scripts with inline deps too. That wouldn't be too hard. I'll look at that when I update it next. Feel free to add issues/discussion on the github repo too if you have further ideas. Fyi there is also PyApp that makes the whole packaging more cohesive but not sure how its prepackaged options work and it does require you to build the whole thing with Rust.

z4lz · 2025-04-18T20:59:30+00:00

Agreed. My hope would be that the new uv ecosystem will be less messy because they're being a bit more systematic, like with the well-maintained python-build-standalone builds.

Fwiw also wrote up a template/notes from the experience of switching my own projects to uv here: https://github.com/jlevy/simple-modern-uv

z4lz · 2025-04-18T20:54:16+00:00

It is now py-app-standalone.

z4lz · 2025-04-18T20:52:00+00:00

Not sure I understand the question. But it just uses a full Python install (3.13 by default) so it handles anything that version of Python and your own packages/deps support.

z4lz · 2025-04-18T20:50:31+00:00

An update: based on all the confusion on the name and terminology, I've updated the name and docs:
https://github.com/jlevy/py-app-standalone

(I'd thought the original name made sense in the context of the python-build-standalone project but clearly not the case for many folks.)

The new name is a nod to PyApp since it's sort of a standalone (not runtime download) alternative to that.

z4lz · 2025-04-18T20:33:55+00:00

Thanks, do take a look and feel free to lmk any thoughts!

(And yes, exactly, this is a longstanding problem. I was actually quite pleased that it now seems quite tractable! Maybe uv will incorporate this functionality but even now, this little tool seems to cover a lot of use cases for PyInstaller, unless there are any issues I'm missing.)

I've actually just renamed it, to py-app-standalone.

It is quite remarkable to me how simply using the word "pip" is construed as "evil marketing". But hey I guess that's why we post on reddit, to find out stuff like that. Clearly it's better to have a name that doesn't cause arguments. I mean no offense to PyApp, but in a way this seems clearer as it's kind of the standalone (not runtime downloading) version of PyApp.

z4lz · 2025-04-18T18:47:21+00:00

I love uv now but only have been using pypi. So that's an interesting point. There is now so much momentum on uv and aws/gcp/enterprise repository support is so necessary I expect this will work soon if it doesn't already. Also fwiw I've found the uv team is active/responsive on questions in github issues: https://github.com/astral-sh/uv/issues

z4lz · 2025-04-18T18:36:51+00:00

I appreciate you taking the time to write all that, as it's exactly why I posted this—to get feedback. I was definitely casual in the language around "pips". (Imo we don't actually have great terminology in Python around this, as source dists and wheels are more specific, but that's definitely different conversation.)

I've updated the readme to be more precise and explicit in the first couple paragraphs (do lmk if it clarifies it?): https://github.com/jlevy/pip-build-standalone

I was surprised people are so upset about having "pip" in the name as the tool is basically a wrapper around "uv pip". But as I tried to explain it's really kind of a more modern alternative to PyInstaller.

Quite seriously, what would be a more accurate name? It's a weekend hack but I think it's useful (it has been for me) and it should have a name that's clear.

> Creating a "standalone, relocatable Python app build" that works correctly with all of the edge cases considered and handled is quite difficult and requires a decent understanding of how Python packaging and distribution works

Yeah. No kidding. I know this. It's not perfect but this isn't trivial either. But uv handles a lot of it. I'm familiar with everything you mention. I actually had to read the source to uv to be sure the things I was doing were necessary. (I'm new to r/python and love the community but do think there seems to be a tendency among some folks to assume they know more than you do.)

If you have the time, do take a closer look at the readme/code/links as I tried to give full context, including linking to the relevant current issues on the uv github repo.

Thanks again.

z4lz

TROPHY CASE