>> По изменению mtime в destdir сборочный тулкит bf определял, запихивать ли файл/директорию в пакет.
> Т.е. проблема была с пустыми каталогами?

А, ну то есть Вы прекрасно понимаете, почему мне таки нужен именно полный аналог `cp -R`, и что я НИКАК не могу его получить? И Вы, оказыватся, прекрасно видите, что у каталогов stat-ы копируются. Чудесно.

> Ведь раз в каталоге есть файл и вы использовали правильную copy_function - mtime скопируется или нет, как вам надо.

Поначалу, как Вы понимаете, у нас просто пропадали файлы из пакетов. А ещё у нас был второй питон, и тащить третий ради одной функции нам не особо хотелось. Так что пришлось написать собственную реализацию с нуля. Забыть бы про это, да уж что было, то было.

>> И некие индивиды-питонисты решили, что будет здорово наплодить сборочных сценариев с copytree.
> В данном конкретном случае я бы сказал нехорошее про "сборочный тулкит".

Не стоит. У него был как ряд изъянов, так и ряд достоинств. В конце концов им пятнадцать лет подряд *по зависимостям* собирались 150 пакетов проекта из более чем 250 репозиториев. Под несколько различных платформ и пакетников. С рассылкой логов по почте. С проставлением fixbuild-ов в Jira. С подсчётом статистики. С публикацией и чисткой репозиториев после сборки. С автоматическими форками всех репозиториев продукта при стабилизации релиза. Такая гибкость, как-никак, заслуживает уважения.

--

Ладно, пора рубить концы, притянутые за уши. Идём с нуля. Ещё раз. Который уже, четвёртый, пятый? Всё-таки терпения у меня вагон. :)

Итак, формулировка. Есть задача, в рамках которой требуется повторить на питоне поведение "cp -R". И в рамках питона, не смотря на наличие стандартных библиотек специально на это заточенных, её либо придётся решать с нуля, либо костылять.

Теперь вопрос. Myhand, Вам намерены и далее утверждать, что Вам не понятны мои претензии к питону? Если нет, то говорить нам больше не о чем: легче и гуманнее будет просто Вас убить. Мы отлично повеселились, но уже поздно, я устал, да и мой выходной закончился. :)