make a src layout the default in our cookiecutter-pyopensci template?

[NickleDave]

currently the template places source code in a folder with the project name in its root

should we instead have the default be a src/ code with the project folder inside that?

as described in https://hynek.me/articles/testing-packaging/#src

and discussed in this issue https://github.com/UBC-MDS/py-pkgs/issues/55

personally I prefer this approach for the two main reasons described in that Hynek post

• it makes the project un-importable from root
  • which makes it much more likely you are running tests on the installed version (that you actually want to test)
  • instead of whatever code is currently in the root of your project (probably the last commit on the "bleeding edge" dev branch, esp. if you are a solo coder without 12 release branches)
• it just makes the structure of the whole project repo more readable:
  • doc, src, tests <-- all are explicit, you don't have to "infer" which one is the source code. And this will be consistent across projects (the source code is always "src")

[xmnlab]

I think that is a good idea.

do you know if there is any PEP about this topic?

maybe we could add an option for that, something like: "source_folder": ["src", "<PROJECT_NAME>"]

[lwasser]

me again. i love all of this input. I think we need to early on define our governance structure for making decisions like this. i know a lot of people don't currently use this approach. Do we have it here but it is suggested? does it become a standard that we enforce in our peer review? governance and process for vetting and accepting new standards I think will need to be discussed soonish before we start making too many decisions! all great discussion and points however!!

[lwasser]

curious - does this assume that tests are being run on the package directly rather than in an environment with the dev version of the package installed? it hadn't occurred to me until just now to consider where the tests are being run when you for instance run CI. if it is running on the directory rather than in the environment that is absolutely problematic!

Your tests do not run against the package as it will be installed by its users. They run against whatever the situation in your project directory is.

But this is not just about tests: the same is true for your application. The behavior can change completely once you package and install it somewhere else.

[xmnlab]

I think it doesn't happen always but it can happen according to the way you import stuff. IIRC the working directory has high priority in the PATH when you call a python script.

[NickleDave]

me again. i love all of this input. I think we need to early on define our governance structure for making decisions like this. i know a lot of people don't currently use this approach. Do we have it here but it is suggested? does it become a standard that we enforce in our peer review? governance and process for vetting and accepting new standards I think will need to be discussed soonish before we start making too many decisions! all great discussion and points however!!

totally understand and agree. hope we can discuss and make sure we include other viewpoints

[NickleDave]

curious - does this assume that tests are being run on the package directly rather than in an environment with the dev version of the package installed? it hadn't occurred to me until just now to consider where the tests are being run when you for instance run CI. if it is running on the directory rather than in the environment that is absolutely problematic!

I think @xmnlab is right that "it's complicated"

More detailed explainer here in this post that Hynek links to: https://blog.ionelmc.ro/2014/05/25/python-packaging/#the-structure