Move `tests` outside the package folder

[buhtz]

Your current folder structure looks like this

orgparse
├── doc
│   ├── ...
│   └── source
│       └── ...
├── ...
├── orgparse
│   ├── date.py
│   ├── extra.py
│   ├── __init__.py
│   ├── inline.py
│   ├── node.py
│   ├── py.typed
│   ├── tests
│   │   ├── data
│   │   │   └── ...
│   │   ├── __init__.py
│   │   ├── test_data.py
│   │   ├── test_date.py
│   │   ├── test_hugedata.py
│   │   ├── test_misc.py
│   │   └── test_rich.py
│   └── utils
│       ├── __init__.py
│       ├── _py3compat.py
│       └── py3compat.py
├── pytest.ini
├── README.rst
├── setup.py
└── tox.ini

The problem in short

Your current folder structure looks like this

orgparse
├── orgparse
│   ├── __init__.py
│   ├── ...
│   ├── tests
│   │   └── *.py

Because of that you ship your package (via pypi or distros) always including your unittests. There is no need for this. The package is blown up, resources (data transfer) are wasted and CO2 produced.

Beside of resources it is unusual today. There are also some other packaing and unittest related problems.

The recommended structure looks like this.

orgparse
├── orgparse
│   ├── __init__.py
│   ├── ...
├── tests
│   └── *.py

Today there are some variants of project folder layouts (e.g. the so called src-layout) but all of them have in common that package folder (in your case orgparse/orgparse) is always separted from the tests folder (orgparse/test).

Because you are using tox I am not able to provide you with a PR. I am sure tox can handle that but I assume that tox need to be reconfigured after modifying the folder structure.

There are also some problems with your unittest invocation which I report in a separate Issue (#56).

[karlicoss]

Hmm, is there a good reason you want to move it out? I think in orgparse specifically it's just always been like that -- but also generally I prefer keeping tests inside the package -- that way it's easy to just go inside the directly with installed package and search for usages etc

[buhtz]

I don't understand what you mean with "just go inside the directly...".

I think I pointed out some good reasons why to change

• It is officially recommended.
• It save the users resources because tests not shipped with release versions anymore.
• Ressource efficient software development in context of climate change and carbon footprint

[karlicoss]

1. "It's officially recommended" -- well, sure, but it's just a convention, and many people prefer to put tests inside package -- you can look up tons of arguments on stackoverflow for it if you're interested
2. It's like a few kilobytes worth of code -- not a big deal in 2022.
3. Same -- if you want to save on carbon, there are much better opportunities to measure performance bottlenecks and optimize rather than saving on few kilobytes of text files which are only copied once in a few months. E.g. I could argue that you save more carbon if you ship tests with the package so when someone wants to look up tests they don't have to open github. Both of these arguments are kinda pointless really since there is no way to measure this impact.

[buhtz]

Dear @karlicoss ,

please let me repeat my Intro from the PR in short:

• Your final decision because you are the maintainer
• I just want to discus and exchange arguments and opinions to learn not to troll ☮️

"It's officially recommended" -- well, sure, but it's just a convention, and many people prefer to put tests inside package -- you can look up tons of arguments on stackoverflow for it if you're interested

I don't see why convention has more value then recommendation especially in an open development and discussion process (e.g. with PEP) like it is done in the Python universe. Not sure how you mean it but I understand convention like "One Mio. flies can't be wrong.". This is not an argument for me. Even pointing to stackoverflow generally isn't an argument. A lot of content (on SO and the WWW) about project folder layout is quit old and outdated. Please refer to an explicit SO-entry if you want to discuss this further. I am not aware of a actual recommendation or arguments to keep "test" inside the package directory. Because you can do it is not an argument to do it.

It's like a few kilobytes worth of code -- not a big deal in 2022.

This isn't about saving hard disk space. It is again about energy and CO2. Even bytes need to get transferred which costs energy. Especially in 2022 it matters!

if you want to save on carbon, there are much better opportunities to measure performance bottlenecks and optimize rather than saving on few kilobytes of text files

But the fact that there are better opportunities doesn't make this Issue here a poor one. Btw: Which "better opportunities" do you see in the context of orgparse.

I could argue that you save more carbon if you ship tests with the package so when someone wants to look up tests they don't have to open github.

I don't get that logic. 1.000 downloads of orgparse (directly and via dependencies) including the tests folder costs much more then just 1 developer cloning your repo via git because of testing.

Both of these arguments are kinda pointless really since there is no way to measure this impact.

The term "measure" is in science a bit wider then you mean it. But the situation that you can't measure something doesn't make it wrong.

At the end I would say you can close that Issue if you won't consider moving the tests folder.

EDIT: Finally found the "official" docu about that. https://packaging.python.org/en/latest/tutorials/packaging-projects/