Support for package_dir

[n1ngu]

Documentation states

Flit looks for the source of the package by its import name. The source may be located either in the directory that holds the pyproject.toml file, or in a src/ subdirectory.

https://flit.pypa.io/en/stable/pyproject_toml.html#module-section

but I'd like to discuss a number of use-cases covered by setuptools package_dir option.

One is placing sources directly in the repository root, covered by package_dir={"mymodule": "."}. I am not a big fan of this layout but it is convenient so that the repository itself can be the importable directory if it is cloned in an importable path instead of installed via pip.

Another use case is not having to make lots of empty parent folders for packages distributing submodules, covered by package_dir={"some.framework.modules.contrib.mymodule": "flatfolder"}. Otherwise one would need a layout such as

repository/
  pyproject.toml
  src/
    some/
      framework/
        modules/
          contrib/
            mymodule/
              __init__.py
              actual_sources.py

Not a big issue but it feels clunky.

It would be awesome if flit could cover this alternative folder layouts so that this kind of projects could switch to flit without a major repository refactor.

[takluyver]

Sorry, but I'm going to say no to this. There's a trade-off between simplicity and covering every possible use case, and the design of Flit has always leant towards simplicity, even when that means giving up some flexibility. Part of that is that you have to use one of two common folder layouts.

I think pushing developers towards common conventions for these things is actually an advantage, because it makes it easier for us to make sense of each others' projects.

Another use case is not having to make lots of empty parent folders for packages distributing submodules, covered by package_dir={"some.framework.modules.contrib.mymodule": "flatfolder"}.

Doing that also breaks the ability to import the package without installing it by manipulating PYTHONPATH or sys.path. I know not everyone will do that, but I think it's a useful enough possibility that I'd rather people put up with the clunky chain of parent folders than do clever tricks with packaging.

I'll close this; feel free to continue discussing it, but I'm not likely to change my mind.