[tool.hatch.build.targets.sdist]
include = [
  "pkg/*.py",
  "/tests",
]
exclude = [
  "*.json",
  "pkg/_compat.py",
]

It takes about 30 seconds of reading the documentation to find this.

Interesting discussion, thanks for the link! I side with pf_moore there; when I think of distributing a library I think of shipping only the library code itself and none of the supporting files, although I can understand the argument to include things like tests/ and docs/.

That said, if you haven't already tailored your project for hatch, configuring only-include is more work than switching to a build backend that just bundles source modules by default. With the right config hatch can do what you like, and I can understand existing users sticking with it, but for newbies I think it's really risky to suggest a build backend that grabs everything it finds in the working directory and packages it up for PyPI. It's just surprising and dangerous default behavior imo.

you just need only-include

https://hatch.pypa.io/1.13/config/build/#explicit-selection

it's easier than changing build backends

and a lot of times tests/ (and docs/) are included with source code in an sdist format - https://discuss.python.org/t/should-sdists-include-docs-and-tests/14578

Even if you're using git or hg for version control you'll probably wind up with more in your sdist than you need: things like uv.lock, Justfile, or the contents of your tests/ dir might not be harmful, but they bloat your sdist and don't really belong there, and hatch will package them up with your source code unless you explicitly configure it not to.

It's the conservative choice, which is maybe not ideal for new projects as it predates many PEPs. Hatch, uv, poetry, pdm, are probably all better modern choices.

i think the conservative choice would be to use setuptools as build backend.

hatch has hardcoded awareness of Git and Mercurial and specifically searches for project-level .gitignore and .hgignore to read those files directly. But it doesn’t handle user-level or system-level config, so anything you have ignored from config outside of your project, like .env in my example, will not be ignored by hatch, and will wind up in your sdist.

ah that probably explains why I didn't have this problem, same reason why I don't like global gitignores

py310 ... nah ... bah ... chigau ... passu ... sochi ga ii

PEP 810
: Explicit lazy imports for faster startup times

Looks awesome!

Something I feel about LLMs, and I'm surprised others aren't feeling it and building tools around it, is that I want to feel in control.

I would prefer if the LLMs made one click ready scripts or patches and then I click the button to execute it, and then the execution of the thing or merging happens without LLM involvement. If find it strange that everyone is so eager to hand the keys to the LLMs first and then put up some minor guard rails.

Cool project though, I can see how that would be desirable.

RNA-Induced Silencing Complex <.< ...5

stubtest (static vs runtime)

rather than

pyrefly coverage check (static only)

So pyrefly is a bean counter. If using mypyc, e.g. black, doesn't have stubs, then understandable this could be a valid use case.

BUT that is an outlier. Without stubs that removes the usefulness of pyright which catches actual bugs.

static vs runtime matters

Similarly to how test coverage measures how much of a library's source code is hit by its tests, type coverage measures what percentage of a library's typables have type annotations.

Errrr no!

type coverage should be how much of the typing has corresponding tests. This is particularly important for stub packages. Which are focused on confirming the advertised typing accurately reflects actual typing.

Hope they didn't cyber squat the package name.

Listen to Yoda, "Try? Either do or do not! No try there is."

The correct answer to percentage of a libraries typables having type annotations is either zero or all. This is advertised by the py.typed file. There is no middle ground.

Wtf is wrong with pyrefly authors?

Stub package with naming starting with type- does not follow PEP561.

The convention is types-*.

So yeah, what is type-coverage?!

Great, now it will be easier for them to program drones used to hunt civilians.

For anyone interested, I recently switched from using ty to Pyrefly and so far I'm very happy with the results. Mypy is more comprehensive, but painfully slow. ty delightfully fast, but lacking Django support is a deal-breaker.

Pyrefly mostly supports Django (unless you get creative with custom querysets) and for me, the trade-off is worth it for the performance.

Tools i recommend:

• rebuff -- finds places in code to replace with better algorithms. Wanted a tool to recommend itertools and itertools-more usage, but achieve that. Chosen cuz it's not Rust.

• typos -- fixes typos in both code and docs

• mypy+pyright+stubtest -- need all of them. pyright phones home. mypy isn't enough it misses way too much.

• pretty format YAML

• cyclonedx-bom -- create software bill of materials

• pip-licenses -- NOTICE.txt and licenses.json Answers question does my toolchain include virus licensed packages?

• interrogate -- Any code documentation missing? Does not enforce documentation quality.

• wreck -- sync requirements files; otherwise it's tedious (i'm the author)

• uv and ruff

If it can be helped, don't want Rust nor nodejs in my toolchain. Recommending to Python coders who are very likely not Rust or node.js experts is malpractice or unethical (call it what you may). If you had a problem with any non-Python packages would be at the mercy of non-Python communities. i'm struggling just with Python community black issue 2514 now you want us to broaden that struggle?

And if people are too dumb or lazy to learn how requirement file hierarchies work, perhaps they shouldn't be Python coders.

Disclosure: author of wreck

Dependabot got annoying. For logging-strict git repo, turned off dependency graph. Blindly updating mostly nodejs crap is insane, it's a supply chain attack waiting to happen.

Disclosure: author of logging-strict

The OP mentioned dealing with user input via pydantic. Which acts schema-like. strictyaml does the same for YAML config files where runtime validated against a schema.

And here is why all the other config file formats are dodgy, why-not written by author of strictyaml (not me).

Disclosure: Author of types-strictyaml, logging-strict, pytest-logging-strict, and sphinx-external-toc-strict. So yes i drank the kool-aid, but welcome challenges to preference for YAML config file format over others.

Don't want individual dependency packages listed within pyproject.toml. Breaks the hierarchical nature of requirements files.

There is only so much enshitification my eyes can endure.

I'm the author of wreck.

Thanks, I'll look into them!

Yes indeed, the 'int' objects are stored and searched in the set based on their value, and the 'Value' objects are stored/searched based on their identity unless you define the above __eq__ and __hash__ methods which cause them to be stored/searched based on value too. This is a Python design decision and that's the point of this exercise. The fact that 'int' is an immutable type and we are replacing isn't relevant. Try replacing/reassigning the 'Value' objects after added __eq__ and __hash__, and you get the same result as for 'int'. So the thing that really matters is how __eq__ and __hash__ are defined, and the default for a user-defined class is as stated in the "Explanation:" above.

Maybe I should also show a class with __eq__ and __hash__ defined based on value, but then it gets a bit long. I'll have to rethink this exercises so that the point comes across better as it now seems to confuse a lot of people based on the down-votes. Thanks for feedback anyway.

I think you're fundamentally misunderstanding the above.

In your first example, you change an attribute of an object. In your case you called it .value but could just as well have been called .jacket.

In the second case you replaced one immutable object with another. You didn't change the "value" attribute of 1002 to 1001. You replaced the entire object, 1002 with a new one: 1001.

I will be sad if Brett Cannon doesn't get a seat. He's done so much to push Python packaging forward.