Ignoring files for "sdist"?

[Spindel]

When running "maturin sdist", I noticed that it's very greedy on files being added to the tarball. Is there a good way to control or ignore various parts of the tree for that? In my case, it started to break due to cross-compile chroot folders in my working dir contained dangling symbolic links.

An obvious solution is of course to keep the project directory "clean", so I'm not really considering this a "bug", more of a "how do I do this?" kind of question.

[messense]

I think we can add support for MANIFEST.in ?

cc @konstin

[messense]

Here is how setuptools implementing this: https://github.com/pypa/setuptools/blob/2234e88b7b820c40f29d7ddadc182b0f130eaa1d/setuptools/_distutils/filelist.py#L104-L175

[konstin]

maturin calls cargo package --list --allow-dirty and puts those files into the source distribution. You can use include and exclude in Cargo.toml, which are seeded from gitignore. In this case 'd recommend to gitignore the cross-compile chroot folders.

As far as I can tell cargo's mechanism covers all relevant usecases of MANIFEST.in, so I don't think we need to support that.

[messense]

If we implement this mixed layout, maybe MANIFEST.in could be useful?

[Spindel]

Thank you, @konstin. The Cargo.toml parts for exclude seem pretty exactly to be what I was after.

[konstin]

If we implement this mixed layout, maybe MANIFEST.in could be useful?

MANIFEST.in is underspecified custom DSL that's much more complex than cargo's gitignore + include/exclude and also lacks the tooling support of the latter (e.g. IDE integration of gitignore as well as git status --ignored and cargo package --list for debugging), so I'd try hard to avoid MANIFEST.in. Most users also already have a reasonable .gitignore so with the cargo solution they don't need to learn any new inclusion/exclusion rules or even add any additional configuration.

[Spindel]

As the user who asked the question, I'm totally fine with the Cargo.toml / .gitignore solution.

Not figuring that out from the documentation was my main problem, ( as it was a "new" project and didn't have any proper commits)

[messense]

I agree supporting MANIFEST.in isn't necessary.

We could do what Poetry does in pyproject.toml if we ever need to add another way to specify includes and excludes.