Paul Ganssle @pganssle@qoto.org

@skunksarebetter Am I mis-remembering, or did you once recommend a CLI tool that would execute a terminal command in response to changes in a set of files? I remember it as being a recommendation for `fzf`, but I'm not seeing that anywhere, and `fzf` doesn't seem to advertise that capability.

@schlink@octodon.social It's a variation on this strategy: https://github.com/pganssle/python-norm-estimate

@schlink@octodon.social The reason for choosing a pseudorandom subset rather than a fixed amount at the beginning or something is that a lot of files have a bunch of "header" or "footer" matter that will be identical. Choosing a random subset, you are more likely to encounter non-identical bits in similar files.

@schlink@octodon.social By the way, I dunno if this is helpful, but a while back I developed an application where I wanted to know if I had duplicate files anywhere on a disk.

Rather than hash the entire disk just to build an index, I used some deterministic algorithm to choose a *small* pseudorandom subset of each file and hash that to build my index. There were collisions among non-duplicate files, but they were few and far between (and often not even among files with the same size), and it was a simple matter to do a full hash on the small subset of files with collisions.

@astrojuanlu Luckily, the gap between FOSS and commercial apps has been closing quickly in the past decade or so.

Unfortunately, that's mostly because commercial / proprietary apps are *also* becoming terrible.

@schlink@octodon.social Look in to `pipx`. That's the most convenient way to install CLI applications from PyPI.

@schlink@octodon.social Strongly disagree with that. We've been actively going the other direction because "built in to the standard library" means "really hard to change and it has to work for absolutely everyone."

I should probably be less negative and more grateful that my employer has allowed me to work on this on work time. Thanks, Google!

Coming soon to Python: A basically full-spec iso8601 parser.

Though I'm already pessimistically expecting a bunch of comments like, "Finally, I still didn't understand why they didn't do that in the first place." and "Oh this function is finally useful, thought the core devs were being intransigent on this."

@saper So you may want to try from that entry point — bootstrap `build` and use that to build wheels for your whole dependency tree yourself. You can do it in a chroot or a docker container or whatever isolated environment mechanism your build system uses to separate context-specific dependencies.

@saper If you are using the normal Python stack, you basically just have to bootstrap to the point where you can get some sort of isolated environment that you can run `pip` or some equivalent in.

Most of the reason distro folks don't usually like doing that sort of thing is because of some notion of mitigating supply chain risks by always installing from "source".

I think this is *mostly* security theater (though there's some core of value to it), but `python -m build` came about mainly because the Arch folks wanted a simple standards-compliant way to bootstrap the build ecosystem.

@saper I think this is a general problem, and not one that's easy to fix. Software is an ecosystem, and even stable ecosystems are in some form of *dynamic* equilibrium, with a constant ebb and flow that tends to wear away static elements.

How you want to orchestrate your builds really depends on you. All the distro packagers do install setuptools globally, but that's because they are trying to maintain a separate packaging stack.

@saper As for the other question, the following paragraph, "If it ain't broke?" explains how the old `upload` endpoint was uploading bad metadata.

There's also PEP 643, which will *really* help clean up dependency resolution when `setuptools` gets supported for it if people are using recent versions of `setuptools`.

@saper In my experience, a lot of the new class of build tools are optimized for making life easier for projects on the "happy path" — simple scripts and pure python projects, etc.

For C extensions or other niche applications, the best supported option is probably still `setuptools`.

Comments available on HN (on the front page now!), subreddits r/Python and r/programming and lobste.rs:

https://lobste.rs/s/ajhbif/why_you_shouldn_t_invoke_setup_py_directly

Latest post is a big one: "Why you shouldn't invoke setup​.py directly"

A lot of people don't know about this because we haven't been great about getting the word out. This blog post is in part an attempt to remedy this.

Please help spread the word!

https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html

@urusan Yeah, pretty sure that's just going to read as "Paul didn't wear a costume". Particularly since I am, in fact, a tech professional.

It needs to be an archetype recognizable to the average person as an actual costume.

@urusan What does that look like?

What outfit do I put on that the average people in my neighborhood will look at me and think, "Oh and he made the robots!"