cosmofy 0.2.0 is available. So many things came together for this release:
Three open source developers I follow (William McGuan, Simon Willison, and Charlie Marsh) were all in a twitter thread where the concept of something like cosmofy was mentioned.
This release represents a very large shift from bundling individual python files to using uv to bundle entire venv directories. The behavior of the CLI is now much more similar to uv in form and function.
When I was designing the low-level zip file manipulation tools for cosmofy, I wanted an easy way to see the contents of the bundle. We're so used to using ls for looking into directories that I thought it would be cool to emulate as much of ls as I could.
But then I realized this was insane. First, many of the options are just aliases for slightly more explicit options. Charlie Marsh would never have a -t that was an alias for --sort=time. Why should I?
In the end I decided to go with the most common options (sorting, list view), a couple that were easy to implement, and a few longer-form ones that cover most of the aliases.
Imitation is the highest form of flattery which is why as part of the cosmofy 0.2.0 release, I decided to change everything about how the CLI behaved to make it work more like the way the tools from Astral work.
I have a long-term plan for Astral to take over making Cosmopolitan Python apps. It's a long shot, but if they do, it'll be a huge win for cross-platform compatible executables. I also saw this popular issue that there should be a uv bundle command that bundles everything up.
To make it easier to adopt, I decided to make the interface follow Astral's style in three important ways:
Subcommand structure: It's gotta be cosmofy bundle and cosmofy self update
Colored output: Gotta auto-detect that stuff. Luckily, I had fun with brush years ago, so I know about terminal color codes.
Global flags: Some of those flags gotta be global.
Smart ENV defaults: smart defaults + pulling from environment variables to override.
Now I didn't start out wanting to build my own argument parser (really, I promise I didn't!). I tried going the argparse route (I even tried my own attrbox / docopt solution), but I had a few constraints:
I really don't want 3rd party dependencies (even my own). cosmofy needs to stay tight and small.
I want argument parsing to go until it hits the subcommand and then delegate the rest of the args to the subcommand parser.
I want to pass global options from parent to child sub-parser as needed.
Together these pushed for a dedicated parser. This lets me write things like:
usage =f"""\
Print contents of a file within a Cosmopolitan bundle.
Usage: cosmofy fs cat <BUNDLE> <FILE>... [OPTIONS]
Arguments:
{common_args}
<FILE>... one or more file patterns to show
tip: Use `--` to separate options from filenames that start with `-`
Example: cosmofy fs cat bundle.zip -- -weird-filename.txt
Options:
-p, --prompt prompt for a decryption password
{global_options}
"""@dataclassclassArgs(CommonArgs):
__doc__ = usage
file:list[str]= arg(list, positional=True, required=True)
prompt:bool= arg(False, short="-p")...defrun(args: Args)->int:...
cmd = Command("cosmofy.fs.cat", Args, run)if __name__ =="__main__":
sys.exit(cmd.main())
For the colored output, I took inspiration from William McGuan's rich which uses tag-like indicators to style text.
π How I Found Myself Running a Microschool (Kelsey Piper / Center for Educational Progress). Over the past 10 years I have migrated to essentially this view: you need direct instruction to get the basics and a foundation; you need to see people enact the values you want to transmit; and you need a strong motivating project to get you over the humps when the going gets tough.
π Ideas Arenβt Getting Harder to Find (Karthik Tadepalli / Asterisk). Knowing what is causing productivity growth to start to slow is critical to selecting appropriate policies for how to get it going again. Karthik makes a good case for why the idea that "ideas are getting harder to find" is wrong and why it's more of a failure of the market to weed out bad ideas and promote good ones.
π Justified (Bite code!). just is a Rust-based task runner and here's a good write up about its features. If I wasn't writing ds (my own task runner), I'd probably use just. I'll probably experimentally support some subset of just's syntax in ds.
π Book Time #26: How I Read (Aaron Gordon / Book Time). My process for selecting books is very different from Aaron's, but it's nice to see someone else's process.
Mine:
I get recommendations from friends, colleagues, podcasts, and other books.
I add them to a list (currently an Amazon Wishlist). I prefer digital books over physical books because I can make them into audiobook (at 4x) and they take up very little physical space.
When I get to the end of the books I have in my queue, I sort the wishlist by price (lowest to highest) and buy everything under $5. That keeps me busy for about 3 months.
I take all the books that I've purchased and sort them by the number of pages (lowest to highest). This is my new reading queue.
There are only a couple of exceptions for me to deviate from this order:
My wife recommends I read something next, especially as it may impact our kids. This bumps the book to the top of the list (both for purchase and reading).
I'm about to meet someone who recently published a book. There have been a few times where I got through their most-recently published book the day before meeting them. HT: Ramit Sethi who teaches the importance of being overly prepared for certain kinds of meetings.
I often get asked how much I retain from the audio versions of books. My informal tests show no more or less than most people when they read books. I don't remember every detail, but neither do most people. HT: Mike Masnick who introduced me to the idea of listening to podcasts at greater than 2x.
π The Writer's Journey: Mythic Structure for Writers, 3rd Edition by Christopher Vogler (2007; via Chanan Berkovits). You may have heard of Joseph Campbell's The Hero with a Thousand Faces, but how about something with more contemporary references? Also, does the obligatory meta thing and shows how the process of writing itself follows the mythic structure.
While I was updating my standard pyproject.toml to use dependency groups, I switched to using uv as my build backend (from setuptools). Like all the other design choices, it has very sensible defaults with good overrides when you need them.
One thing that it doesn't support is dynamic versions (i.e. reading __version__ from __init__.py). Charlie Marsh explains:
Using dynamic metadata for things that are actually just static lookups feels like the wrong tradeoff.
Like version = ["dynamic"] to read the version from __init__.py.
As soon as you have dynamic metadata, you need to install dependencies and run Python just to get that info.
Static metadata rules. Just write the version out twice!
This makes sense, but I really didn't want to write out the version twice. Luckily, uv has a nice uv version command to change/bump the version number in the pyproject.toml, so I started thinking about how I'd also change the version in the __init__.py at the same time.
I asked ChatGPT what the best approach was and it suggested something quite different: don't write the value in __init__.py at all.
from importlib.metadata import version, PackageNotFoundError
try:
__version__ = version("package-name")# from pyproject.toml: project.nameexcept PackageNotFoundError:
__version__ ="0.0.0"# aka unknown version
In my previous post, I argued that absent a standard place to put dev dependencies in pyproject.toml, we should opt to use optional-dependencies. However, dependency groups seem to offer a nice standard place for such dependencies: these are bundles of dependencies that don't get built into the final distribution (i.e. they are not required to run the package).
Feels like the best of both worlds and uv already started using dependency-groups.dev as the place that uv add --dev writes to and this group is sync'd by default when using uv sync and uv run.
I only really got this when I read Simon Willison's post about how he's using dependency groups to make it easier for people to hack on his code.
π Remix: Making Art and Commerce Thrive in the Hybrid Economy by Lawrence Lessig (2002; via Tribe of Mentors & Joseph Gordon Levitt). I knew most of these ideas from having read TechDirt for so many years and listening to Lessig talk about these ideas for several decades. Still, I was surprised how much of the fights we have today still stem from a basic disagreement about copyright and how art gets made.
π Closed: Bad error messages from blog post (Facebook). Turns out pyrefly developers saw my previous post, broke things down into many sub-issues and fixed them all. pyrefly now reports zero errors in castfit and the errors it find in other repos have pretty understandable error messages!
π Power: Why Some People Have Itβand Others Don't by Jeffrey Pfeffer (2010; via Robin Hanson). A blend of anecdotes and social science experiments that didn't replicate. The networking bits seemed fine. Everything else was kinda meh.
π Remote: Office Not Required by Jason Fried & David Heinemeier Hansson (2013; via Iridescent Learning). It's interesting to see how work from home policies have ebbed and flowed since 2013.
π Why 98.5% of organizations have slow actions/checkout (Chris Goller / depot; via Changelog News). I'm hesitant to fiddle with the git internals, but the sparse checkout and partial clone sound like easy things to try. (Most of GitHub Actions were sped up by using uv.)
π Deploying to Amazon's cloud is a pain in the AWS younger devs won't tolerate (Corey Quinn / The Register; via Changelog News). Hilarious take, but so true. It took me 7 years to be able to close a handful of student accounts (who had inactive emails after graduation) that were still charging my billing account, but whose EC2 instances were not visible to me because of AWS permissions issues.
π Game design is simple, actually (Raph Koster). Clickbait title aside, there are twelve compact and useful design lessons each of which is a whole world unto itself.