Comments 63
А для пользователей Windows это работает?
По крайней мере должно (cython умеет собирать dll, cx_Freeze без проблемм собирает exe). Сегодня буду эксперементировать — обязательно отпишусь о результатах.
Хмм… А можно как-то собирать виндовую сборку из линукса? А то лениво каждый раз грузить винду в виртуалке для сборки…
Если и да — я не нашел как это сделать. Так что по ходу собирать придеться в 4 разных окружениях.
Значит, нельзя. py2exe не умеет так как пользуется поиском зависимостей по установленной версии — включая поиск по DLLкам. Так что еще важно следить, чтобы ставились системы совместимые с target. Сборка на win7 может не заработать с ходу на winxp — надо вырезать некоторые ошибочно попавшие DLLки. Сборка с P4 может не завестись на P3 — ибо numpy «all-in-one» ставит оптимальную для системы (с SSE3) сборку, а там даже SSE нету. В общем, тот еще бубен.
мы как-то под Wine собираем exe-шки с Nullsoft инсталлятором, но я подробностей не знаю правда
Под вайном (проще всего) или mingw64 подсистему собирать.
py2exe
pyinstaller
pyinstaller
Получилось собрать на винде небольшое приложение таким образом. Причем numpy cython'ом скомпилировался.
Добавляем еще py2exe, чтобы запускать под виндой если оно кросс.
Добавляем компиляцию с -O -O0 чтобы еще и удалить докстринги.
Смотрим на sourceforge.net/projects/decompyle/ вздыхаем, понимаем что все защиты от честных людей.
Добавляем компиляцию с -O -O0 чтобы еще и удалить докстринги.
Смотрим на sourceforge.net/projects/decompyle/ вздыхаем, понимаем что все защиты от честных людей.
Decompyle Вам не поможет с модулями собранными как сишные библиотеки ;)
А, действительно, cython же… Жаль, не всё на нём работает. У меня в зависимостях болтается pygtk, matplotlib, numpy и прочие радости — очень хочется ускорить это всё добро, но не работает оно ни на чем кроме ванильки cpython'а.
Разве все что здесь пишут можно так вот просто декомпилировать — все пробовали?
Есть у меня подозрение, что что-то не так ©
Во-первых, титуальная задача довольно странная. Для динамического языка, которым является питон, одним из основополагающих свойств является полная интроспекция — тоесть возможность для любого фрагмента кода получить и модифицировать по имени класс, метод, аргументы, переменные и так далее. Соответственно, что бы мы не делали с программой, в ней будет сохранена большая часть исходников — чтобы работала интроспекция. Поэтому защитить ничего не получится.
Питон — не единственный динамический язык с интроспекцией. Теми же свойствами обладает, среди прочих, JavaScript. И для него задача «защиты» исходного кода изучается уже много лет. Насколько я знаю, на данный момент наиболее популярное решение — обфускация — изменение исходного кода, при котором он сохраняет работоспособность, но имена всех идентфикаторов (классов, методов, переменных и прочего) меняются на «a», «b», «c» и так далее. Такой код можно «декомпилировать» — только человек его все равно не сможет нормально читать.
И последнее. Насколько я понял, описанное в статье заклинание использует Cython — некую тулзу, которая позволяет компилировать небольшое подмножество Python в С, а затем получившийся код на C — в исполняемый файл. Насколько я понимаю, поправьте меня если я не прав, у данного подхода два серьезных минуса. Во-первых, компиляции поддаются только простейшие программы на Python — никакая интроспекция в C не переносится. Во-вторых, теряется одно из основных преимуществ питона, кроссплатформенность — скомпилированный код можно будет запустить только на той платформе, под которую он собран.
В целом странно все это.
Во-первых, титуальная задача довольно странная. Для динамического языка, которым является питон, одним из основополагающих свойств является полная интроспекция — тоесть возможность для любого фрагмента кода получить и модифицировать по имени класс, метод, аргументы, переменные и так далее. Соответственно, что бы мы не делали с программой, в ней будет сохранена большая часть исходников — чтобы работала интроспекция. Поэтому защитить ничего не получится.
Питон — не единственный динамический язык с интроспекцией. Теми же свойствами обладает, среди прочих, JavaScript. И для него задача «защиты» исходного кода изучается уже много лет. Насколько я знаю, на данный момент наиболее популярное решение — обфускация — изменение исходного кода, при котором он сохраняет работоспособность, но имена всех идентфикаторов (классов, методов, переменных и прочего) меняются на «a», «b», «c» и так далее. Такой код можно «декомпилировать» — только человек его все равно не сможет нормально читать.
И последнее. Насколько я понял, описанное в статье заклинание использует Cython — некую тулзу, которая позволяет компилировать небольшое подмножество Python в С, а затем получившийся код на C — в исполняемый файл. Насколько я понимаю, поправьте меня если я не прав, у данного подхода два серьезных минуса. Во-первых, компиляции поддаются только простейшие программы на Python — никакая интроспекция в C не переносится. Во-вторых, теряется одно из основных преимуществ питона, кроссплатформенность — скомпилированный код можно будет запустить только на той платформе, под которую он собран.
В целом странно все это.
Во-первых, компиляции поддаются только простейшие программы на Python
C многопоточным gui-приложением (PyQt) проблемм не возикло ;)
скомпилированный код можно будет запустить только на той платформе, под которую он собран
Иногда лучше собрать под 4 платформы, чем потом найти свой код в приложении конкурента.
C многопоточным gui-приложением (PyQt) проблемм не возикло ;)
Простейшие по коду питона, а не используемых библиотек. Все ограничения написаны в инструкции к Cython, их много и они достаточно жесткие.
Иногда лучше собрать под 4 платформы, чем потом найти свой код в приложении конкурента.
Как я уже писал ниже, ИМХО динамический язык с интроспекцией — не лучшее решение для тиражируемого closed-source решения.
то ли я чего-то не понимаю, то ли вот они все ограничения.
Нет, речь вот об этом: wiki.cython.org/Unsupported
Спасибо. Я бы не назвал это жесткими ограничениями.
А по ссылке оттуда вот сюда бы еще зайти wiki.cython.org/enhancements
я на первое что наткнулся — в неподдержку CEP 307 в 0.14.1, потом попробую 0.15.
Еще из «жестких ограничений» имхо 305.
я на первое что наткнулся — в неподдержку CEP 307 в 0.14.1, потом попробую 0.15.
Еще из «жестких ограничений» имхо 305.
К слову, у меня вот есть еще DSLи, которые на ply сделаны. Что-то мне подсказывает, что cython это тоже не прожуёт…
Иногда лучше найти свой код в приложении конкурента и подать в суд, чем гадать есть он в приложении конкурента или нет.
Объясните, в каких случаях требуется не отдавать исходники заказчику?
Потому что я на месте заказчика больше никогда бы не стал работать с компанией, которая предоставила продукт, с которым я больше ничего не смогу сделать. И всем знакомым заодно рассказал.
Другое дело, когда речь о массовом приложении, но тут уже нет внешнего заказчика, а есть только клиенты.
Потому что я на месте заказчика больше никогда бы не стал работать с компанией, которая предоставила продукт, с которым я больше ничего не смогу сделать. И всем знакомым заодно рассказал.
Другое дело, когда речь о массовом приложении, но тут уже нет внешнего заказчика, а есть только клиенты.
ИМХО, использование динамического языка для тиражируемого closed-source решения — это не лучший выбор. Обычно используют нативное ядро и платформонезависимую логику на динамическом языке. Например, большая часть клиентов Dropbox так сделано. Но при этом если вытащить и декомпилировать из него весь код на питоне, то рабочего приложения мы не получим, потому как ядро — на C/C++/Objective-C/Whatever.
Вы прави, имелся в виду именно клиент.
UFO just landed and posted this here
Я отстал от жизни, или cython научился компилить «обычные» python скрипты без какой либо доработки?
И еще при таком подходе:
Никогда не выносите mainloop (для GUI) в модуль! Я как то три дня бился над тем, почему у меня приложение не работало. Собирал с помощью py2exe, в main.py было лишь import myapp, в котором и был весь код (делал так для того чтобы можно было обновления легко накатывать). Потом прочитал о том что все импорты должны быть завершены.
Так что:
import myapp
myapp.mainloop()
И еще при таком подходе:
Никогда не выносите mainloop (для GUI) в модуль! Я как то три дня бился над тем, почему у меня приложение не работало. Собирал с помощью py2exe, в main.py было лишь import myapp, в котором и был весь код (делал так для того чтобы можно было обновления легко накатывать). Потом прочитал о том что все импорты должны быть завершены.
Так что:
import myapp
myapp.mainloop()
Научился. Только вот беда заключается в том, что тестируется это все на простейших приложениях. В больших проектах, хоть как-то использующих декораторы и интроспекцию, начинают вылезать редкоземельные баги.
Да, научился. Выше упоминался ряд несерьезных, ИМХО, ограничений.
Моя задача (кроме получения новой информации для себя лично) — предупредить о потенциальных проблемах этой технологии, исходя из личного опыта. Если бы с компиляцией питона в натив все было хорошо — это бы делали все. Но все это не делают :). Основная задача проекта Cython — облегчение написания нативных расширений для питона. И позиционируется он как вообще другой язык с «близким к пиону синтаксисом». Так что не по назначению инструмент используем, что череповато последствиями.
Блин, ткнулся для проверки в первый же модуль приложения, и вот те на те ёж в томате:
datacompboy@nuuzerpogodible:~/work/kvarta/himlab$ cython -v src/chrom_analyse.py
Compiling /home/datacompboy/work/kvarta/himlab/src/chrom_analyse.py
chrom_analyse.py:702:26: Generators are not supported
версия cython?
ответил выше
Вопрос по билд-системе: cx-freeze сам вызывает cython и gcc для сборки, или нет?
Есть ли готовые авто-системы резолва и сбора зависимостей, чтоб «ext_modules» само собралось?
Есть ли готовые авто-системы резолва и сбора зависимостей, чтоб «ext_modules» само собралось?
UFO just landed and posted this here
ИМХО, это нечестно — закрывать исходный код. Заказчик заплатил Вам деньги (нанял Вас), и код, получается, принадлежит ему, а Вы его не одтаете.
Да, Вы правы, правильнее наверно было бы написать «клиент». Но статья не о том ;)
С чего вы взяли что заказчик заплатил за исходный код?
Заказчик заплатил за разработку продкута. Значит, результат — его собственность. Исходный код, помимо скомпилированных бинарников, и есть результат процесса разработки.
Это вы уже додумали. Заказчик мог заплатить за решение задачи. Простой пример, заказали бюст, в процессе изготовление было сделано специальное долото. Для показа бюста долото не нужно. Почему заказчику нужно отдать и инструмент?
Это может и должно оговариваться отдельно.
Это может и должно оговариваться отдельно.
На сколько знаю, если с заказчиком, работодателем или еще кем-то заключается договор, в котором явно это указано, то все, что сделал и изобрел работник во время решении поставленной задачи — принадлежит работодателю.
Но да, вы правы, это должно быть описано в договоре. Плюс такой договор должен быть составлен и подписан.
Но да, вы правы, это должно быть описано в договоре. Плюс такой договор должен быть составлен и подписан.
От договора зависит.
Cython, кстати, умеет создавать и исполняемые файлы, а не только библиотеки-модули для импорта. Используя ключ --embed можно обойтись без cx_Freeze.
Sign up to leave a comment.
Как обезопасить исходники своего python-приложения