Отнюдь

щас может что-нибудь ещё вещнут

Then, avoid making the common mistake of storing unit tests outside the package directory. These tests should definitely be included in a subpackage of your software so that they aren’t automatically installed as a tests top-level module by setuptools (or some other packaging library) by accident. By placing them in a subpackage, you ensure they can be installed and eventually used by other packages so users can build their own unit tests.

Что скажете? Всегда тесты рядом с пакетом  складывал, а тут говорят не надо так

> They can be installed and eventually used by other packages to build their unit tests
Вот это вообще сомнительное утверждение. IMHO не надо так.

почему не надо? Щас кирилл прийдет и расскажет как у него тесты делаются..
Лично мне не нравятся тесты внутри пакета. Они засаряют код, особенно если учесть, что как правило тесты пишутся "неряшлевей".

Тесты должны проверять код своего пакета. Я что-то не вижу как этому поможет использование кода тестов внешнего пакета.

Чтоб засорить код тестами, надо тесты в коде писать, а так вроде никто никогда не делает. Или делает?

внутри пакета там в смысле что папка tests которая часто лежит в корне репозитория, должна переместиться в пакет, а не в смысле раскидать файлы с тестами по всему проекту (как в го например делается и вполне ничего).

Гошечка не включает код тестов в результирущий бинарь, а setup.py установит их

ну поскольку я любитель билдаута, то у меня репозитории проектов устроены как то так:

bin/  # генериться билдаутом
project1/ 
    api
   model
   tests
   setup.py 

project2
    api
   model
   tests
   setup.py

buildout.cfg
project1.cfg
projec2.cfg

В силу особенностей питона projectX это не пакеты.

А если я пилю либу, то тесты у меня вне пакета, сразу из рута. Смысла ставить тесты для мелкой либы нет.

Но если ты пилишь штуку которую можно назвать core, то тут тесты должны быть внутри этого пакета, именно, чтобы в проектах где используется эта core, можно было бы брать наработки тестов для core

Всегда в таком подходе есть двусмысленность.
Что такое "есть смысл или нет"
Открываю я пакет, вижу содержимое.
Открываю гитхаб, с которого пакет якобы собран, вижу другое содержимое.
Помечаю пакет как стрёмный и ищу дальше.
Или так только я делаю?

Так ещё и с докерами происходит часто, сложно понять а правда ли имидж на хабе собран из этой репы.
Но там хотя бы скрипты и логика, легко запутаться не разобравшись.

Остаётся только собирать все самоку  из исходников (:

Кстати можно попробовать так код писать - прям рядом с каждой функцией фигачить фикстуры и тесты. Интересно, как это выглядеть будет

Независимо от того где лежат тесты, всегда можно объяснить setuptools-у, что бы он не включал их в дистриб если вам это не нужно - так что это вообще не довод ни для какого варианта расположения тестов.
Я кладу тесты внутри "пакета". Если это "мелкая" либа, то это будет либо один файл tests.py или это будет суб-пакет tests в котором будет несколько файлов вида test_something.py.
А если это большой проект, состоящий из небольших "приложений" (в стиле django). То внутри каждого "приложения" будут лежать его собственные тесты. Мне так проще их искать и работать с ними, когда код, который они тестируют, лежит тут же рядом, и не надо "пол-экрана" скролить от "внешней" папки с тестами до папки с приложением.

Ну и до того как мы перешли на pytest, мы могли запускать тесты "ядра бекенда", которое было установлено из "дистриба" как зависимость к "кастомизации бекенда под клиента". Это позволяло проверить, что ничто в самом ядре не поломалось от того, что было "кастомизировано" под клиента. С pytest это уже не получается, т.к. у него не работает как надо (хотя вроде и есть в возможностях) запуск тестов в установленном пакете. pytest всё равно будет искать свои настройки и фикстуры в текущей папке (и выше по иерархии) и найдёт там настройки и фикстуры от "кастомизации".

Не очень красиво, и кроме того придётся в prod ставить тестовые зависимости, иначе у тебя импорты, которые нужны только тестам, "поломаются" и потянут за собой продакшен код.

Прям в коде можно писать либо совсем примитивные тесты без зависимостей. Либо док-тесты, которые, что логично, не выполняются без специального ранера, который их запустит.