Support for src structure

[henryiii]

Src structure has some important benefits. Running something like pytest needs /src structure or otherwise it loads from the local folder instead. If you have compiled extensions, or if you use importlib stuff, it's critical to load the installed package, not the local folder. See, for example, scikit-build/cmake-python-distributions#145, which was motivated by scikit-build/cmake-python-distributions#139 (comment) for an example of problems in the wild.

However, not having editable support for now makes it a bit less attractive, since regular layout can run without installing in a pinch (if you avoid things like importlib), so maybe it would be best to wait till editable support is available (maybe best to use PEP 517 editable mode if it comes? PEP 660 or 662, whichever is accepted).

[henryiii]

Whey uses:

[tool.why]
source-dir = "src"

Similar spelling and such would be nice unless there's a reason to do something differently, I'd think. Flit simply discovers /src structure automatically, so there's no setting for it there.

[FFY00]

I am trying to think what would be a good name for this setting. So far we have source-include, which allows users to add extra files to the sdist (we are very conservative about that, to prevent including unwanted files), and top-level-modules, to override the Python module names (we default to the Python-ized name of the package, eg. hello-world>hello_world, we want to promote using the same module name as the package name).

We already use "source" to refer to the project source, so I am leaning to module-location. We could also rename source-include to project-source-include, opening up the possibility for source-location, but I am not it would be enough. Though, I think renaming source-include would probably be beneficial either way.

@henryiii what do you think?

[henryiii]

Edit before sending: I see your edits, module-location is okay - I like the similarity with top-level-module. I don't think source-include needs to be renamed, it's clear as is, and refers to what is placed in the source. (sdist-include would also be fine?) Original comment below:

Well, given that this is often named "/src", I think it's highly advantageous to call it something with source in it. The second item could be "location" or "directory" (or "dir" for short). In other packages, it has a strong tendency to be called "dir" - setuptools calls it package_dir. Whey calls it source-dir, which I like pretty well. Poetry and flit both automatically discover it, and refer to it by name as src layout, such as in pypa/flit#115.

I'm not really fond of using package-dir, since it's not actually the package dir, but the dir that contains the package dir, IMO. package-location isn't bad, but I do like dir/directory better than location. So my favorites are:

• source-dir: No need to create fragmentation with another tool (whey) if there's no reason to. I don't think this conflicts with source-include; if it was source.dir and source.include I'd be a bit picker, though, so maybe a little.
• source-directory: No need to save typing
• package-location: Meh, not horrible.

[FFY00]

I think I am gonna go with module-location then.

[henryiii]

I think that's consistent with what's already there, and quite readable. 👍

[henryiii]

This is merged now, so can be closed?

[FFY00]

Yes.