Комментарии 22
Это вообще что?
У меня и без этой магии opencv на третьем питоне работает
Альтернативу в виде установки opencv через pip попробовали?
Нет.
Менеджер pip нарушается принцип "чистой среды", загружая из сторонних источников исполняемый код, созданный третьими лицами.
Любой менеджер пакетов так работает. Это нормально, пока он один.
Библиотеки numpy и opencv есть в архиве дистрибутива. Они собраны с соблюдением зависимостей и устанавливаются системным менеджером пакетов ( apt ) гарантированно оставаясь в зоне ответственности поставщика.
Если какой-либо штатный пакет требует модернизации, то он пересобирается из исходных текстов штатными средствами с переводом в зону ответственности разработчика прикладной системы.
Сохраняется гибкость разработки, гомогенность системы и понятное разделение ответственности сторон: поставщик дистрибутива - прикладной разработчик.
Специализированные пакетные менеджеры ( pip, npm, ... ) оправдывают себя в вычислительных средах без системной зависимости пакетов, без системного пакетного менеджера, например, MSDOS, MS Windows и др.
Но, если уже есть системный пакетный менеджер ( apt ), то зачем нужен нужен ещё один, решающий лишь частные задачи?
Специализированные пакетные менеджеры снижают надёжность, открывая "дверь" для исполняемого кода третьих сторон, что подтверждается множеством негативных примеров типа "left-pad". При этом третья сторона остаётся вне зоны ответственности.
А оно надо?
Через apt так же можно загрузить вредонос, как часто люди читают исходники?
Пакет apt находится в зоне ответственности поставщика дистрибутива.
Если простой системы случается в силу ошибочного функционирования пакета apt, что легко определяется, то ответственность за простой системы обоснованно делегируется из зоны разработчика в зону поставщика дистрибутива или клиента, установившего пакет из архива третьей стороны.
Вопрос: как и кому делегировать ответственность за простой системы, полученный через загрузку "вредоноса" второстепенным пакетным менеджером из архива третьей стороны?
как часто люди читают исходники?
Люди не читают исходники. Чтение исходников - привилегия программистов.
Программисты- не люди?
А почему в статье вы ставите OpenCV из исходников, а не с помощью apt тогда?
Ну и насчёт надёжности. Python 2.7 и 3.5 давно не поддерживаются и не получают обновления безопасности.
Установка cv2 из исходных текстов обоснована ошибкой, вынесенной в заголовок статьи.
Установка из исходников позволила обновить версию cv2 до крайней стабильной (4.5.5) без нарушения гомогенности среды исполнения, без издержек на виртуализацию и прочее.
Стабильный релиз cv2 равноправно представлен в средствах прототипирования без дискриминации по диалекту ( Python2 и Python3 )
Ну и насчёт надёжности. Python-2.7 и Python-3.5 давно не поддерживаются
Консервативный подход к средствам прототипирования удешевляет разработку в силу того, что критические ошибки в диалектах Python-2.7 и Python-3.5 давно исправлены, а "косяки" известны.
Да, и глупо требовать какую-либо надёжность от прототипа. Достаточно отсутствия "глюков".
Коммерческий продукт планируется в другой среде разработки, максимально раскрывающей возможности OpenCV.
А линукс которым вы пользуетесь не сделан из исходного кода, созданного третьими лицами?
Нет.
В этом случае ответственность разделяется между двумя сторонами:
- поставщик дистрибутива;
- разработчик прикладной системы.
Поставщик отвечает за ошибки в пакетах дистрибутива.
Разработчик прикладной системы отвечает за ошибки в собранных им пакетах.
В лицензионном соглашении обычно пишут что никто ни за что не отвечает.
На коммерческие системы, содаваемые в рамках гражданских договоров, это правило не распространяется.
Более того, гражданский договор обычно содержит раздел типа "ответственность разработчика", где может быть указана финансовая ответственность разработчика в виде денежного штрафа за каждый час простоя коммерческой системы.
Я надеюсь, что коммерческие системы всё же не клеят из убунты, bash скриптов и изоленты
Коммерческие системы, прежде всего, находятся в зоне ответственного контроля разработчика.
Другими словами, разработчик персонально отвечает за работу своей системы без сбоев и аварий.
При этом причина сбоя, аварии не имеет значения, ибо клиент получает убытки от факта простоя системы без относительно причины простоя.
Выбор средств разработки коммерческой системы находится в области компетенции разработчика.
"Цифровая гигиена разработки" так же находится в области компетенции разработчика.
Вопрос лишь в том, готов ли разработчик подписать гражданский договор со штрафными санкциями за факты простоя системы на этапе эксплуатации, в том числе по причинам, зависящим от действия или бездействия третьих сторон?
Не думаю что такой пункт в договорах часто встречается. Иначе стоимость разработки будет увеличиваться, как и ее время. Так же в стоимость будут включены риски поломок.
Финансовая ответственность разработчика за качество фиксируется в любом грамотном договоре, но часто имеет "обтекаемую" формулировку.
Например: "Разработчик обязуется исправлять ошибки за свой счёт в течение <такого-то времени> после запуска системы в эксплуатацию".
Экономический смысл "обтекаемой" формулировки тот же самый - финансовые издержки разработчика по закрытым обязательствам.
Если в гражданском договоре нет пункта, фиксирующего финансовую ответственность разработчика за качество работы, то это первый "звоночек" для пристального изучения заказчика до подписания договора.
В любом случае, культура производства программ и цифровая гигиена - эффективный способ страхование рисков своих финансовых потерь в будущих периодах.
исправлять ошибки
Только исправление ошибок - это не тоже самое, что и поддержка продуктов, обновление системы безопасности, исправление уязвимостей.
"Ошибки" - это когда ваша программа работает не так, как в ТЗ, происходят сбои, и вот это нужно фиксить, исправлять.
То, что ПО , возможно, подвержено какими-то вариантам взлома , и вы должны вычитать все исходники - это уже совсем другой пункт.
CPU у вас тоже собран из рассыпухи, а не третьими лицами? Чтобы ни закладок ни уязвимостей не было...
Аппаратная безопасность находится вне зоны ответственности прикладного программирования.
Другими словами, если система откажет по причинам, зависящим от оборудования, что легко выясняется, то это не может быть основанием для претензий клиента к разработчику программы.
Более того, желание клиента поменять оборудование, платформу, например, заменить интел на арм или что-то там ещё, автоматически становится основанием для выставление клиенту дополнительного счёта за работы по переносу программы на другую аппаратную платформу.
Python3 — ImportError: No module named 'cv2'