Hello, I just wanted to announce that my multi-year rewrite is over and Hatch is now ready to use!
There were 3 main reasons I rewrote the project from scratch:
Timing - I’m a stickler for standards and 5 years ago there wasn’t much that existed or things were experimental. Now we have well thought out PEPs 517/518, 621/631, 639, 643, 660, etc. and implementing those will not lead to extra work later on since everything is mostly finalized.
Scope - I kept getting feature requests for actual features and due to my mistake of making things too opinionated, which would have caused burn out if I didn’t halt development.
Environments - I’ve always wanted to run things in not just virtual environments but in arbitrary environments, and have a way to statically defined matrices without using ini files.
So now:
The build backend Hatchling was created and implements all the relevant packaging standards.
All functionality is plugin-based, with defaults based on community standards, so users can extend as desired like getting the version from Git or building things other than wheels and sdists.
There’s already a plugin for running things within Docker and much to my surprise TOML turned out to be a fantastic format for expressing environment configuration.
I consider the project to be mostly feature-complete (due to the plugin system) except for the following things that I couldn’t do without user input:
Ability to download/install/manage Python versions on all platforms that virtual environments could then use (my old idea was to use/wrap Miniconda but they added a warning that cannot be silenced so we can’t)
Ability to parallelize command execution in multiple environments, I want it to be pretty and have an interactive option to expand to full size output based on keypresses so you can check on the progress of any at will
A dep show graph command
I also plan on finding a way to ship binaries for each platform.
I think this looks fantastic! It clearly has had a lot of work and attention! Thank you!
It’s wonderful to see how many of the modern standards can integrate to create a smooth development experience. I think this is how many experienced with python implicitly understand how things can work together in our own projects like this, but for beginners, it can be incredibly frustrating getting lost in the weeds of PEPs and never knowing which standard applies in which circumstances or what is deprecated or not.
I particularly like that it can be used for both application and library development. The plugin mechanism seems quite extensive as well for the situations where you do need to deviate from the basics / conventions.
Now for the slightly negative opinion. Unfortunately, I feel that many day-to-day python programmers working in industry are crying out for a lock-file experience. See the success of poetry, PDM, pip-tools (and probably others). I think Hatch will struggle to gain much adoption without that because it’s the most prominent missing piece. I see we are both waiting anxiously for metadata-only resolve with `pip download --dry-run --report`! by cosmicexplorer · Pull Request #10748 · pypa/pip · GitHub If that looks too far away, is there any thought in using something light-weight like pip-tools in the short-term to give you a pretty solid lockfile? In next release of pip it will give access to the internal resolver of pip, so it’s as close to a standard as one could reasonably achieve at the moment.
Hello, congratulations for 1.0 milestone. Install multi version is always pain in Linux and windows because you need to install other tools like pyenv. How hatch support install more than one python version on linux and windows? Is the interface like pyenv?
Agree, for a beginner in programming like me, pyenv is good enough but too many options. In Linux if python built from source tools need to inform what package needs to be installed and in windows maybe just use official installer from python.org. Also, pyenv don’t show progress bar when installing python, maybe using rich progress bar will give a good visual.
It needs some work to push it over the finish line – I know at least Brett and I are both interested in seeing it happen, but we’re both pretty distracted. But perhaps you’d like to help? And in any case, you’re welcome to use the PyPI-compatible repo at https://pybi.vorpus.org/ to pull down prebuilt Python binaries.
Just bear in mind (unless they’ve changed something) that these are built specifically for their own images, and may not transfer to other OS versions or layouts (and I believe the Windows packages just run the regular installer and assume Admin privileges).
Nathaniel’s efforts are much more likely to be what you want.
I’ve dragged @barry into this as well at work (but that’s all the progress as of late ), but that’s as far as I will go hear as I don’t want to drag this topic into a tangent on building relocatable CPython binaries.
FYI, @jjhelmus put together give-me-python · PyPI for a PyCon lightning talk (in a day) after seeing my “think outside the box” slide at PyCon. It’s a manylinux compatible Python wheel. (as in, it’s Python as a wheel). Don’t known if expanding this would be a viable way to provide alternate Python implementations for hatch/nox/tox/etc, but interesting concept.
will give a good visual.
), but that’s as far as I will go hear as I don’t want to drag this topic into a tangent on building relocatable CPython binaries.