Сборка / тестирование проекта Python с расширениями C

У меня есть проект с пакетом python и скомпилированным компонентом внутри из этого. Текущая структура каталогов:

<project>
  foo/
  foo/__init__.py
  foo/...

  src/
  src/c_foo.c

  tests/
  tests/test_foo.py

  setup.py

Когда проект построен, distutils создает каталог build / lib , который я либо добавляю в PYTHONPATH , либо устанавливаю в виртуальную среду. Результирующая структура следующая:

<project>
  build/lib
  build/lib/foo/__init__.py
  build/lib/foo/c_foo.so

Проблема в том, что если я запускаю сеанс интерпретатора Python из корня проекта, запускаю тесты из корня проекта и т. Д., Он выбирает исходное дерево вместо построенного дерева.

Я нашел несколько существующих решений этой проблемы:

1. Поместите исходные коды Python в отдельный каталог, например. lib / foo , modules / foo и т. Д. Обратной стороной этого является дополнительный уровень каталогов для всех исходных файлов и несогласованность с проектами, которые не имеют скомпилированных расширений и, следовательно, имеют свои пакеты python в корневом каталоге.

2. Храните пакеты в корневом каталоге, что означает неудобство, связанное с необходимостью выхода chdir из корня проекта (например, в каталог tests /), чтобы интерпретатор python не видел исходные пакеты (через сценарий сборки или вручную).

3. Храните пакеты в корневом каталоге под другим именем (например, foo-module или foo-lib ) с соответствующим package_dir = {'foo': 'lib-foo'} строка в setup.py . Это вариант pt. 1 без дополнительного уровня иерархии каталогов, что, я полагаю, почти то же самое.

4. Храните пакеты в корне и используйте setup.py build_ext --inplace , однако это загрязняет исходный код tree.

В любом случае вводятся накладные расходы по сравнению с простым проектом на Python, где можно изменять / запускать код прямо из исходного дерева. Мне бы очень хотелось услышать мнение каждого о плюсах и минусах вышеизложенного и о том, какой именно метод вы используете для своих проектов.