В заголовке известная ошибка python3.
Интерпретатор python2 импортирует opencv без ошибок при установке совместно с python3 в единой среде исполнения.
Краткая инструкция по локализации ошибки далее.
Среда исполнения
Дистрибутив линукс с длинным циклом поддержки.
Установлены все стабильные обновления.
Все пакеты развёрнуты системным менеджером ( apt ) или сборкой в среде исполнения из исходных текстов штатными средствами.
Установлены штатным способом два интерпретатора: python-2.7 и python-3.5.
Пакетов со стороны, пакетов собранных вне среды исполнения, нарушенных зависимостей, конфликтов версий нет.
Признаки ошибки
Ошибка возникает на этапе загрузки библиотеки opencv в интерпретаторе python‑3.5.
Причина ошибки
Причина ошибки — разные файловые структуры у python‑2.7 и python‑3.5; отличие системы индексов версий в именовании каталогов и файлов.
В одном случае, python‑2.7, один индекс версии — 2.7.
В другом случае, python‑3.5, три индекса версии — 3, 3.5 и 3.5m.
Конфигуратор сборки opencv устанавливает файловые пути python3 подобно python2.
Сборка и установка модулей opencv для python3 производится с ошибками файловой структуры.
Локализация ошибки
Ошибка исправляется через уточнение связанных параметров cmake с последующей установкой opencv из исходных текстов.
CMAKE_BUILD_TYPE:STRING=Release
OPENCV_FORCE_PYTHON_LIBS:BOOL=ON
OPENCV_PYTHON3_VERSION:BOOL=ON
PYTHON2_EXECUTABLE:FILEPATH=/usr/bin/python2.7
PYTHON2_INCLUDE_DIR:PATH=/usr/include/python2.7
PYTHON2_INCLUDE_DIR2:PATH=/usr/include/x86_64-linux-gnu/python2.7
PYTHON2_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libpython2.7.so
PYTHON2_LIBRARY_DEBUG:FILEPATH=
PYTHON2_NUMPY_INCLUDE_DIRS:PATH=/usr/lib/python2.7/dist-packages/numpy/core/include
PYTHON2_PACKAGES_PATH:PATH=/usr/lib/python2.7/dist-packages
PYTHON3_EXECUTABLE:FILEPATH=/usr/bin/python3
PYTHON3_INCLUDE_DIR:PATH=/usr/include/python3.5m
PYTHON3_INCLUDE_DIR2:PATH=/usr/include/x86_64-linux-gnu/python3.5m
PYTHON3_LIBRARY:FILEPATH=/usr/lib/x86_64-linux-gnu/libpython3.5m.so
PYTHON3_LIBRARY_DEBUG:FILEPATH=
PYTHON3_NUMPY_INCLUDE_DIRS:PATH=/usr/lib/python3/dist-packages/numpy/core/include
PYTHON3_PACKAGES_PATH:PATH=/usr/lib/python3/dist-packagesЗаключение
Ошибка локализована параметрами cmake.
Для других сред исполнения и версий python3 уточнять параметры cmake по‑обстоятельствам.
Комментарии (22)
gwisp
02.03.2022 10:29+1Альтернативу в виде установки opencv через pip попробовали?
numeric Автор
02.03.2022 10:34-11Нет.
Менеджер pip нарушается принцип "чистой среды", загружая из сторонних источников исполняемый код, созданный третьими лицами.
unsignedchar
02.03.2022 10:49+5Любой менеджер пакетов так работает. Это нормально, пока он один.
numeric Автор
02.03.2022 12:04-3Библиотеки numpy и opencv есть в архиве дистрибутива. Они собраны с соблюдением зависимостей и устанавливаются системным менеджером пакетов ( apt ) гарантированно оставаясь в зоне ответственности поставщика.
Если какой-либо штатный пакет требует модернизации, то он пересобирается из исходных текстов штатными средствами с переводом в зону ответственности разработчика прикладной системы.
Сохраняется гибкость разработки, гомогенность системы и понятное разделение ответственности сторон: поставщик дистрибутива - прикладной разработчик.
Специализированные пакетные менеджеры ( pip, npm, ... ) оправдывают себя в вычислительных средах без системной зависимости пакетов, без системного пакетного менеджера, например, MSDOS, MS Windows и др.
Но, если уже есть системный пакетный менеджер ( apt ), то зачем нужен нужен ещё один, решающий лишь частные задачи?
Специализированные пакетные менеджеры снижают надёжность, открывая "дверь" для исполняемого кода третьих сторон, что подтверждается множеством негативных примеров типа "left-pad". При этом третья сторона остаётся вне зоны ответственности.
А оно надо?
pfffffffffffff
02.03.2022 19:35Через apt так же можно загрузить вредонос, как часто люди читают исходники?
numeric Автор
02.03.2022 22:18Пакет apt находится в зоне ответственности поставщика дистрибутива.
Если простой системы случается в силу ошибочного функционирования пакета apt, что легко определяется, то ответственность за простой системы обоснованно делегируется из зоны разработчика в зону поставщика дистрибутива или клиента, установившего пакет из архива третьей стороны.
Вопрос: как и кому делегировать ответственность за простой системы, полученный через загрузку "вредоноса" второстепенным пакетным менеджером из архива третьей стороны?
как часто люди читают исходники?
Люди не читают исходники. Чтение исходников - привилегия программистов.
masai
03.03.2022 01:09А почему в статье вы ставите OpenCV из исходников, а не с помощью apt тогда?
Ну и насчёт надёжности. Python 2.7 и 3.5 давно не поддерживаются и не получают обновления безопасности.
numeric Автор
03.03.2022 02:45Установка cv2 из исходных текстов обоснована ошибкой, вынесенной в заголовок статьи.
Установка из исходников позволила обновить версию cv2 до крайней стабильной (4.5.5) без нарушения гомогенности среды исполнения, без издержек на виртуализацию и прочее.
Стабильный релиз cv2 равноправно представлен в средствах прототипирования без дискриминации по диалекту ( Python2 и Python3 )
Ну и насчёт надёжности. Python-2.7 и Python-3.5 давно не поддерживаются
Консервативный подход к средствам прототипирования удешевляет разработку в силу того, что критические ошибки в диалектах Python-2.7 и Python-3.5 давно исправлены, а "косяки" известны.
Да, и глупо требовать какую-либо надёжность от прототипа. Достаточно отсутствия "глюков".
Коммерческий продукт планируется в другой среде разработки, максимально раскрывающей возможности OpenCV.
bungu
02.03.2022 10:52+4А линукс которым вы пользуетесь не сделан из исходного кода, созданного третьими лицами?
numeric Автор
02.03.2022 11:16-4Нет.
В этом случае ответственность разделяется между двумя сторонами:
- поставщик дистрибутива;
- разработчик прикладной системы.
Поставщик отвечает за ошибки в пакетах дистрибутива.
Разработчик прикладной системы отвечает за ошибки в собранных им пакетах.unsignedchar
02.03.2022 11:51+4В лицензионном соглашении обычно пишут что никто ни за что не отвечает.
numeric Автор
02.03.2022 12:17-2На коммерческие системы, содаваемые в рамках гражданских договоров, это правило не распространяется.
Более того, гражданский договор обычно содержит раздел типа "ответственность разработчика", где может быть указана финансовая ответственность разработчика в виде денежного штрафа за каждый час простоя коммерческой системы.
unsignedchar
02.03.2022 17:06Я надеюсь, что коммерческие системы всё же не клеят из убунты, bash скриптов и изоленты
numeric Автор
02.03.2022 19:24Коммерческие системы, прежде всего, находятся в зоне ответственного контроля разработчика.
Другими словами, разработчик персонально отвечает за работу своей системы без сбоев и аварий.
При этом причина сбоя, аварии не имеет значения, ибо клиент получает убытки от факта простоя системы без относительно причины простоя.
Выбор средств разработки коммерческой системы находится в области компетенции разработчика.
"Цифровая гигиена разработки" так же находится в области компетенции разработчика.
Вопрос лишь в том, готов ли разработчик подписать гражданский договор со штрафными санкциями за факты простоя системы на этапе эксплуатации, в том числе по причинам, зависящим от действия или бездействия третьих сторон?
pfffffffffffff
02.03.2022 19:38Не думаю что такой пункт в договорах часто встречается. Иначе стоимость разработки будет увеличиваться, как и ее время. Так же в стоимость будут включены риски поломок.
numeric Автор
02.03.2022 22:52Финансовая ответственность разработчика за качество фиксируется в любом грамотном договоре, но часто имеет "обтекаемую" формулировку.
Например: "Разработчик обязуется исправлять ошибки за свой счёт в течение <такого-то времени> после запуска системы в эксплуатацию".
Экономический смысл "обтекаемой" формулировки тот же самый - финансовые издержки разработчика по закрытым обязательствам.
Если в гражданском договоре нет пункта, фиксирующего финансовую ответственность разработчика за качество работы, то это первый "звоночек" для пристального изучения заказчика до подписания договора.
В любом случае, культура производства программ и цифровая гигиена - эффективный способ страхование рисков своих финансовых потерь в будущих периодах.
TimsTims
03.03.2022 08:37исправлять ошибки
Только исправление ошибок - это не тоже самое, что и поддержка продуктов, обновление системы безопасности, исправление уязвимостей.
"Ошибки" - это когда ваша программа работает не так, как в ТЗ, происходят сбои, и вот это нужно фиксить, исправлять.
То, что ПО , возможно, подвержено какими-то вариантам взлома , и вы должны вычитать все исходники - это уже совсем другой пункт.
Shmaiser
03.03.2022 08:20CPU у вас тоже собран из рассыпухи, а не третьими лицами? Чтобы ни закладок ни уязвимостей не было...
numeric Автор
03.03.2022 09:54-1Аппаратная безопасность находится вне зоны ответственности прикладного программирования.
Другими словами, если система откажет по причинам, зависящим от оборудования, что легко выясняется, то это не может быть основанием для претензий клиента к разработчику программы.
Более того, желание клиента поменять оборудование, платформу, например, заменить интел на арм или что-то там ещё, автоматически становится основанием для выставление клиенту дополнительного счёта за работы по переносу программы на другую аппаратную платформу.
atc
Это вообще что?