Can you tell me what the problem is for you when you click the first link? I tried to make it work for all browsers (even mobile, but the UI isn't very mobile friendly), so I would like to get it working on your system too. If you can give me a bug report (and maybe try from different system), that would be great.

The second link explains:

• mutability: https://github.com/bterwijn/memory_graph#mutable-type
• shallow copy: https://github.com/bterwijn/memory_graph#copying-values-of-mutable-type
• difference between x += y and x = x + y: https://github.com/bterwijn/memory_graph#name-rebinding

It's left to the reader to generalize this to x |= y vs x = x | y.

The dict union operator is similar to that of set, but in addition the right operand overwrites values of keys of the left operand. It's a nice operator once you get used to it.

Easy to make a mistake with this exercise:

• first realize b = b | {3: []} makes a shallow copy
• then realize the shallow copy still references the value of key 2 in a so we can still append to that and change a

As a C programmer, this reads as a shitpost lol. Best I can do is interpret this in Tcl, but I'm lost with |=

Not too familiar with the union operator for dicts, but that result was not what I expected.

First link is broken, second doesn't lead to what's claimed.

I'm more of of a Meowth trainer but okey

I wouldn't try to follow hunches on how tool that has extensive and accessible documentation works, your novice is a strawman that has expectations but unable to do anything for some reason. So he should completely change the workflow.

Nothing personal, I liked your article in general, but pretending that default is all there is isn't great way to frame it, you could have linked relevant documentation and provided a snippet on how it should be done instead of dismissing it entirely, because default doesn't meet your expectations

Then why did you claim nix fixed it? 🤨

This doesn't explain that hatch will package everything in the project directory by default. As a new user making a package, why would you think to look for hatch configuration options?

I mentioned in the article (maybe you don't read that carefully?) that hatch can be configured to do what you need, but if you're just following the packaging guide, which doesn't mention this behavior or provide any kind of heads up to new users, you won't be aware that it is going to even try to look at a directory like .jj. And why would it? I wouldn't expect a compiler or a tool like Maven to look at files that aren't needed to build the project. Why does hatch?

Your demonstration just shows if you're already aware of the problem and you know the cause of the problem, you can find a solution. I say as much in the article and agree with the point. The point of my article is this is surprising default behavior and it's better to just use a tool that has sensible defaults.

You see, I've actually read your article, you even linked to the hatchling site yourself. It takes little effort. Demonstration

Please, you’ve wasted a lot of time writing the article without bothering to read documentation

? I linked directly to the documentation I read, and that's how I wound up using hatch in the first place. Did you read my article...? Reading the official Python documentation is what led to me uploading my .jj folder and a gitignored .env file to PyPI and writing this post. And writing the post was not a waste of time.

uv_build requires to use uv and not everyone likes it or wants to use it

That's fine. I'm sure there are other build backends that work similarly to uv_build and only grab what's needed to distribute your library. The point isn't that everyone needs to use uv_build, the point is that hatch has surprising and imo dangerous default behavior.

ig nix isn't the best not for every use case then

Caution

If you use setuptools, please be aware that some features that predate standardisation efforts are now deprecated and only temporarily kept for compatibility.

In particular, do not use direct python setup.py invocations. On the other hand, configuring setuptools with a setup.py file is still fully supported, although it is recommended to use the modern [project] table in pyproject.toml (or setup.cfg) whenever possible and keep setup.py only if programmatic configuration is needed. See Is setup.py deprecated?.

Other examples of deprecated features you should not use include the setup_requires argument to setup() (use the [build-system] table in pyproject.toml instead), and the easy_install command (cf. pip vs easy_install).

https://packaging.python.org/en/latest/guides/tool-recommendations/

it's just easier to have a modern hassle-free setup with the other tools

The problem is the default. It's seemingly opt-out, not opt-in. That leads to experiences like these.

how so?

the article doesn't mention the many ways you can define what (not) to include that hatch offers.

There is no way for xyz to be either included or excluded from a package cuz everyone should be running python -m build and checking the tarball and .whl before even considering a commit or a release.

So although the OP chose hitch that doesn't change the workflow of manually checking the tarball.

I use setuptools, wreck (requirements management), and drain-swamp (choose versioning by either "tag" or "current" rather than specifying exact semantic version). What i use has no bearing on the opinion above.

"modern" means you are a little bitch. I'm very tired of that term. A function with multiple return statements is considered "modern". Whereas i see that as wrong. So now that "modern" word is being thrown around for packaging?! Please stop using that term. It's a cope for not being able to code your own build backend (drain-swamp), frame stack free locals inspection (logging-strict), and requirements management (wreck)!

Use whatever you are familiar with without peer pressuring others.

Thank you. That seems quite problematic. I would expect the build backend only to include what I tell it to. IIRC pyproject has a field to tell which packages exist in the project and I'd expect only that to be included + what was specified e.g resources like images.

Uh how? It doesn't have a lockfile for python projects and uv2nix triggers a rebuild everytime you garbage collect nix.

yeah cross compilation is very slow

Please, you've wasted a lot of time writing the article without bothering to read documentation (it's mentioned in both python guide and on the hatchling page), which takes one click and like three paragraphs down, and uv_build requires to use uv and not everyone likes it or wants to use it. Anyway reading documentation is far more important for beginners than automagical tools that supposedly solve all the problems in the world.

But takes forever to set up (at least for me, when I set it up for cross compilation)

Let me say it

N I X F I X E S T H I S

Actually working out the right configuration for your project is likely going to take you more than 30 seconds. And finding the documentation for how to do this is only quick if you know exactly where to look and what to look for. When you invoke pyproject-build it's not clear that hatch is the piece of the puzzle that's causing unexpected files to wind up in your sdist.

And this is still more config and overhead than simply choosing a build backend with more sensible default behavior like uv_build.