Add an exclude patttern for wheels (and use it for flit-core)

[cjmayo]

Allows files to be included in the sdist but not installed.
Useful for established projects that have tests as a subdirectory of the
package directory.

---

flit-core 3.9.0 installs an __init__.py and 6 submodules plus 161 files (including byte-code files) in 44 directories
under a tests directory.

Draft because there is no documentation or tests at the moment. If there is a likelihood of it getting merged I can have a go at those.

[takluyver]

Thanks! And thanks especially for opening this as a prototype, so I don't feel so much obligation to accept it.

My leaning is no - Flit doesn't aim to cover every possibility, and I'm not sure I see many use cases for this one. I believe the main argument for putting tests inside a package folder is that they do get installed, so end users can conveniently run the tests. If we don't want them to be installed, I think the best solution is to move them outside. I come from the scientific Python world, where installed tests are the norm, but indeed it doesn't make sense for flit_core, and I should move them out.

Do you see major reasons why projects which don't want tests installed should do this rather than moving their tests out of the package? Of course moving them might require some changes to CI config, or to imports in test code, but I don't think it should be much work, and it's a one-time thing.

Do you see any other reasons why you might want files inside the package folder in the sdist, but not installed?

[takluyver]

I've opened #691, which moves the flit_core tests out of the package folder, as a point of comparison for this.

[cjmayo]

Added the one line I missed.

Thanks! And thanks especially for opening this as a prototype, so I don't feel so much obligation to accept it.

I was going to just open an issue asking the question. But after a look at the code it wasn't going to take much to implement it, so we may as well see what we are talking about.

Do you see major reasons why projects which don't want tests installed should do this rather than moving their tests out of the package? Of course moving them might require some changes to CI config, or to imports in test code, but I don't think it should be much work, and it's a one-time thing.

That clearly is the "modern" way.

https://packaging.python.org/en/latest/tutorials/packaging-projects/#creating-the-package-files

But it was seeing the recent updating of https://github.com/pallets-eco/flask-admin where they chose flit that made me think about this in the first place. (It also made me look at other instances I had installed, then I say flit-core itself). With all the other change going on there, proposing adding one line to pyproject.toml was going to be easier - for them - but yes not for you as you have to then maintain it. So that maybe isn't fair and the push should be for projects to modernize.

Do you see any other reasons why you might want files inside the package folder in the sdist, but not installed?

Certainly with Gentoo Linux the tests can be executed after building but not installed

https://projects.gentoo.org/python/guide/distutils.html#source-archives

[takluyver]

It certainly makes sense to include tests in the sdist, but I don't see anything in the Gentoo info saying that the tests need to be inside the package directory - and I'd be surprised if Gentoo expected that, given that major Python packages like requests and pip have their tests outside the package directory.

I'm not too concerned about the implementation complexity - though that is a small factor - but in the long run I think it's better for everyone to have fewer different ways to structure a project. We're not going to get rid of the choice between tests inside the package folder & installed vs. outside & not installed, but I don't see a good argument for tests inside the package folder but not installed. I accept that a project already set up that way & migrating to Flit would have an easier time in the short term if that was an option. But longer term I think it's better to push them to pick one of the 2 options that all packages built with Flit use, rather than creating a third option so they don't have to change.

I'm just about to go away for a few days. I'm thinking that if no more compelling use case has come up by the time I get back, then I'll close this and merge #691. Of course, if you think I'm not getting something or not giving something sufficient weight, feel free to make that case too. And thanks for the idea & the discussion, in any case. 🙂

[cjmayo]

Merging #691 would be part of a consistent position. Personally I tend towards there being a shortage of people's time so anything that makes lives easier, but once the API is created it is more difficult to get rid of. Plus people do have a choice, hatchling allows full control over the contents of the wheel.