"Dist currently only works with Git or Mercurial repos" when running simple example

[dtromb]

I'm trying to setup a Python project which will compile a meson subproject and provide a Python interface to it.

Following the example on the website, I created a meson.build which simply declares a subproject, and the git repository for that project has been cloned into ./subprojects/<dep_name>, relative to my project's root:

project('myprojectname')

dep_name_proj = subproject('dep_name')

When I run python -m build, I get the error:

Dist currently only works with Git or Mercurial repos
ERROR Backend subprocess exited when trying to invoke build_sdist

Does this mean to imply that I cannot use meson-python unless /my/ project is in a Git or Mercurial repository? If not, what am I doing wrong?

[dnicolodi]

It is possible to create a source distribution only from the content of a Git or Mercurial repository. build by default builds a package by building an sdist first, and then a wheel from that. For the first point, this does not work if the package is not committed to a Git or Mercurial repository. If you want to test your package, you can instruct build to do not go through the build of an sdist using the -w command line flag.

[dtromb]

I see, ty. -w is what I was looking for! I didn't know meson had a distribution feature built-in, and therefore didn't know that meson-python used it...

[eli-schwartz]

Meson is perfectly fine building projects without a git repo, but it assumes for purposes of creating official release tarballs that you start with version control and export out of it.

Building release tarballs is a relatively niche process. Even developers working on projects rarely do it because there is typically one release manager for many devs, and releasing new versions is a whole event involving the management of the project's commitment to its users (namely: API/ABI stability and versioning, software reliability, testing, and possibly translation freezes and maintenance of a documentation site).

Meson's tooling is designed to work well with that, and to ensure you don't accidentally ship something you never committed.

For some reason I've never quite understood, some people in the standards groups want to run maintainer release.management on every build. I think it may be related to the belief that python software is different from all other software, e.g. python software can't have build configurations, can't have version numbers which aren't on PyPI (because lockfiles), sdists are "special and definitely not just a tarball of source code that has been released and can be built" and therefore the lessons learnt by the rest of the software world (and by python, 15 years ago!) do not have information worth data mining for ideas about solutions.

Anyway, point is that building an sdist is something you do when you want to publish to PyPI, and for no other reason. Defaulting to build one (especially just so it can extract the sdist and build it is a UX issue, but for "build" (and IIRC some versions of pip).