There is no formal statement because there is no formal recommendation. It was chosen as the default because it is easier to use for newcomers and at the time (and still) had stable releases that supported the latest packaging PEPs rather than setuptools’ beta support.
It is also important to note that because of the pipenv debacle any official future recommendation would be kind of tricky.
No, and cannot technically be deprecated until something else can build extension modules (which I am working on with Henry, albeit slowly). That is the final piece of the goal set out in the abstract of PEP 517.
No project should feel compelled to do anything but if there is a desire to move metadata from
pyproject.toml then I personally would recommend Hatchling for ease of use, among other reasons which I plan to outline in a dedicated document soon.
Perhaps others could chime in for this one but my interpretation of Flit is that it will be forever required to build the few core packages like
packaging because it vendors its dependencies which makes bootstrapping for distributions easier.
That is an open question! The following is my personal opinion:
The original, and unchanging, philosophy of Hatch is that its defaults are based on accepted standards and you can mix and match tools so if you only wanted it for the Hatchling build system you could just do that or if you wanted to only use it for its environment management you could only do that. Basically, if you wanted to you could use a different tool for every part of managing a Python project: creation, building, versioning, publishing, environment management, Python installation management, etc.
While I still think you can do all that and Hatch will always allow that, I was conflating could with should. I am increasingly of the opinion that the Python ecosystem would benefit from having a recommended user-facing packaging tool like Cargo and npm.
What opened my eyes recently was doing a month long embed on a Rust team at work. I simply did not realize how much friction is encountered and uncertainty exists which I mostly avoid due to the fact I am already experienced and know what to use, when, and how. If packaging in that ecosystem was not as streamlined as it is then onboarding and teaching beginners would be quite the task, and would look similar to how Python is now where each team or organization must document the workflow that they specifically have chosen.
I think this thread is talking about 5 different things which I think should be broken up:
- A recommended user-facing packaging/project management CLI and build backend
- The continuation of building core packaging logic in dedicated libraries like
installer which will make the ecosystem more accessible for distributions and things like Bazel, and also allow for easier maintenance of and less dependence on pip
- The ability to better integrate with the Conda ecosystem e.g. their packages being available outside that ecosystem
- The intricacies of native code (as I mentioned Henry has funding for and is working on this)
- Lock files (which there is already a thread for and Brett is incrementally working on)
I am trying to tackle 1, which is mostly a UX challenge and is the direction chosen currently by Hatch in that it is a wrapper for many other tools and based on plug-ins for extensibility. I don’t want to restate what has already been said but I basically agree with everything in the second and third comments.