Комментарии 63
А для пользователей Windows это работает?
0
По крайней мере должно (cython умеет собирать dll, cx_Freeze без проблемм собирает exe). Сегодня буду эксперементировать — обязательно отпишусь о результатах.
0
Хмм… А можно как-то собирать виндовую сборку из линукса? А то лениво каждый раз грузить винду в виртуалке для сборки…
0
Если и да — я не нашел как это сделать. Так что по ходу собирать придеться в 4 разных окружениях.
0
Значит, нельзя. py2exe не умеет так как пользуется поиском зависимостей по установленной версии — включая поиск по DLLкам. Так что еще важно следить, чтобы ставились системы совместимые с target. Сборка на win7 может не заработать с ходу на winxp — надо вырезать некоторые ошибочно попавшие DLLки. Сборка с P4 может не завестись на P3 — ибо numpy «all-in-one» ставит оптимальную для системы (с SSE3) сборку, а там даже SSE нету. В общем, тот еще бубен.
0
мы как-то под Wine собираем exe-шки с Nullsoft инсталлятором, но я подробностей не знаю правда
+1
Под вайном (проще всего) или mingw64 подсистему собирать.
0
py2exe
pyinstaller
pyinstaller
0
Получилось собрать на винде небольшое приложение таким образом. Причем numpy cython'ом скомпилировался.
0
Добавляем еще py2exe, чтобы запускать под виндой если оно кросс.
Добавляем компиляцию с -O -O0 чтобы еще и удалить докстринги.
Смотрим на sourceforge.net/projects/decompyle/ вздыхаем, понимаем что все защиты от честных людей.
Добавляем компиляцию с -O -O0 чтобы еще и удалить докстринги.
Смотрим на sourceforge.net/projects/decompyle/ вздыхаем, понимаем что все защиты от честных людей.
+1
Decompyle Вам не поможет с модулями собранными как сишные библиотеки ;)
0
А, действительно, cython же… Жаль, не всё на нём работает. У меня в зависимостях болтается pygtk, matplotlib, numpy и прочие радости — очень хочется ускорить это всё добро, но не работает оно ни на чем кроме ванильки cpython'а.
0
А тот же гтк идет не в виде библиотек (.dll, .so)?
В случае с PyQt например достаточно всего лиш скопировать библиотеку в папку собранного проекта.
В случае с PyQt например достаточно всего лиш скопировать библиотеку в папку собранного проекта.
-3
Разве все что здесь пишут можно так вот просто декомпилировать — все пробовали?
0
Есть у меня подозрение, что что-то не так ©
Во-первых, титуальная задача довольно странная. Для динамического языка, которым является питон, одним из основополагающих свойств является полная интроспекция — тоесть возможность для любого фрагмента кода получить и модифицировать по имени класс, метод, аргументы, переменные и так далее. Соответственно, что бы мы не делали с программой, в ней будет сохранена большая часть исходников — чтобы работала интроспекция. Поэтому защитить ничего не получится.
Питон — не единственный динамический язык с интроспекцией. Теми же свойствами обладает, среди прочих, JavaScript. И для него задача «защиты» исходного кода изучается уже много лет. Насколько я знаю, на данный момент наиболее популярное решение — обфускация — изменение исходного кода, при котором он сохраняет работоспособность, но имена всех идентфикаторов (классов, методов, переменных и прочего) меняются на «a», «b», «c» и так далее. Такой код можно «декомпилировать» — только человек его все равно не сможет нормально читать.
И последнее. Насколько я понял, описанное в статье заклинание использует Cython — некую тулзу, которая позволяет компилировать небольшое подмножество Python в С, а затем получившийся код на C — в исполняемый файл. Насколько я понимаю, поправьте меня если я не прав, у данного подхода два серьезных минуса. Во-первых, компиляции поддаются только простейшие программы на Python — никакая интроспекция в C не переносится. Во-вторых, теряется одно из основных преимуществ питона, кроссплатформенность — скомпилированный код можно будет запустить только на той платформе, под которую он собран.
В целом странно все это.
Во-первых, титуальная задача довольно странная. Для динамического языка, которым является питон, одним из основополагающих свойств является полная интроспекция — тоесть возможность для любого фрагмента кода получить и модифицировать по имени класс, метод, аргументы, переменные и так далее. Соответственно, что бы мы не делали с программой, в ней будет сохранена большая часть исходников — чтобы работала интроспекция. Поэтому защитить ничего не получится.
Питон — не единственный динамический язык с интроспекцией. Теми же свойствами обладает, среди прочих, JavaScript. И для него задача «защиты» исходного кода изучается уже много лет. Насколько я знаю, на данный момент наиболее популярное решение — обфускация — изменение исходного кода, при котором он сохраняет работоспособность, но имена всех идентфикаторов (классов, методов, переменных и прочего) меняются на «a», «b», «c» и так далее. Такой код можно «декомпилировать» — только человек его все равно не сможет нормально читать.
И последнее. Насколько я понял, описанное в статье заклинание использует Cython — некую тулзу, которая позволяет компилировать небольшое подмножество Python в С, а затем получившийся код на C — в исполняемый файл. Насколько я понимаю, поправьте меня если я не прав, у данного подхода два серьезных минуса. Во-первых, компиляции поддаются только простейшие программы на Python — никакая интроспекция в C не переносится. Во-вторых, теряется одно из основных преимуществ питона, кроссплатформенность — скомпилированный код можно будет запустить только на той платформе, под которую он собран.
В целом странно все это.
+23
Во-первых, компиляции поддаются только простейшие программы на Python
C многопоточным gui-приложением (PyQt) проблемм не возикло ;)
скомпилированный код можно будет запустить только на той платформе, под которую он собран
Иногда лучше собрать под 4 платформы, чем потом найти свой код в приложении конкурента.
-1
C многопоточным gui-приложением (PyQt) проблемм не возикло ;)
Простейшие по коду питона, а не используемых библиотек. Все ограничения написаны в инструкции к Cython, их много и они достаточно жесткие.
Иногда лучше собрать под 4 платформы, чем потом найти свой код в приложении конкурента.
Как я уже писал ниже, ИМХО динамический язык с интроспекцией — не лучшее решение для тиражируемого closed-source решения.
+8
Нет, речь вот об этом: wiki.cython.org/Unsupported
0
Спасибо. Я бы не назвал это жесткими ограничениями.
0
А по ссылке оттуда вот сюда бы еще зайти wiki.cython.org/enhancements
я на первое что наткнулся — в неподдержку CEP 307 в 0.14.1, потом попробую 0.15.
Еще из «жестких ограничений» имхо 305.
я на первое что наткнулся — в неподдержку CEP 307 в 0.14.1, потом попробую 0.15.
Еще из «жестких ограничений» имхо 305.
0
К слову, у меня вот есть еще DSLи, которые на ply сделаны. Что-то мне подсказывает, что cython это тоже не прожуёт…
0
Иногда лучше найти свой код в приложении конкурента и подать в суд, чем гадать есть он в приложении конкурента или нет.
0
Вы доверяете судам вашей страны?.. А мы — нет.
-1
Да какая разница? Судов других всё равно нет, так что вопрос вообще так не стоит. Что бы вы там не накопмилили, всё равно это можно запихать внутрь другого кода, вопрос только в цене вопроса.
+1
НЛО прилетело и опубликовало эту надпись здесь
Объясните, в каких случаях требуется не отдавать исходники заказчику?
Потому что я на месте заказчика больше никогда бы не стал работать с компанией, которая предоставила продукт, с которым я больше ничего не смогу сделать. И всем знакомым заодно рассказал.
Другое дело, когда речь о массовом приложении, но тут уже нет внешнего заказчика, а есть только клиенты.
Потому что я на месте заказчика больше никогда бы не стал работать с компанией, которая предоставила продукт, с которым я больше ничего не смогу сделать. И всем знакомым заодно рассказал.
Другое дело, когда речь о массовом приложении, но тут уже нет внешнего заказчика, а есть только клиенты.
+11
ИМХО, использование динамического языка для тиражируемого closed-source решения — это не лучший выбор. Обычно используют нативное ядро и платформонезависимую логику на динамическом языке. Например, большая часть клиентов Dropbox так сделано. Но при этом если вытащить и декомпилировать из него весь код на питоне, то рабочего приложения мы не получим, потому как ядро — на C/C++/Objective-C/Whatever.
+1
Вы прави, имелся в виду именно клиент.
-1
НЛО прилетело и опубликовало эту надпись здесь
Я отстал от жизни, или cython научился компилить «обычные» python скрипты без какой либо доработки?
И еще при таком подходе:
Никогда не выносите mainloop (для GUI) в модуль! Я как то три дня бился над тем, почему у меня приложение не работало. Собирал с помощью py2exe, в main.py было лишь import myapp, в котором и был весь код (делал так для того чтобы можно было обновления легко накатывать). Потом прочитал о том что все импорты должны быть завершены.
Так что:
import myapp
myapp.mainloop()
И еще при таком подходе:
Никогда не выносите mainloop (для GUI) в модуль! Я как то три дня бился над тем, почему у меня приложение не работало. Собирал с помощью py2exe, в main.py было лишь import myapp, в котором и был весь код (делал так для того чтобы можно было обновления легко накатывать). Потом прочитал о том что все импорты должны быть завершены.
Так что:
import myapp
myapp.mainloop()
0
Научился. Только вот беда заключается в том, что тестируется это все на простейших приложениях. В больших проектах, хоть как-то использующих декораторы и интроспекцию, начинают вылезать редкоземельные баги.
+2
Моя задача (кроме получения новой информации для себя лично) — предупредить о потенциальных проблемах этой технологии, исходя из личного опыта. Если бы с компиляцией питона в натив все было хорошо — это бы делали все. Но все это не делают :). Основная задача проекта Cython — облегчение написания нативных расширений для питона. И позиционируется он как вообще другой язык с «близким к пиону синтаксисом». Так что не по назначению инструмент используем, что череповато последствиями.
+4
Блин, ткнулся для проверки в первый же модуль приложения, и вот те на те ёж в томате:
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
+1
версия cython?
0
ответил выше
0
Вопрос по билд-системе: cx-freeze сам вызывает cython и gcc для сборки, или нет?
Есть ли готовые авто-системы резолва и сбора зависимостей, чтоб «ext_modules» само собралось?
Есть ли готовые авто-системы резолва и сбора зависимостей, чтоб «ext_modules» само собралось?
0
Нет, не вызывает.
Насчет авто-резолва не в курсе.
Хотя да, есть мысль что автоматизировать процесс можно при надобности.
Насчет авто-резолва не в курсе.
Хотя да, есть мысль что автоматизировать процесс можно при надобности.
0
НЛО прилетело и опубликовало эту надпись здесь
ИМХО, это нечестно — закрывать исходный код. Заказчик заплатил Вам деньги (нанял Вас), и код, получается, принадлежит ему, а Вы его не одтаете.
0
Да, Вы правы, правильнее наверно было бы написать «клиент». Но статья не о том ;)
-1
С чего вы взяли что заказчик заплатил за исходный код?
0
Заказчик заплатил за разработку продкута. Значит, результат — его собственность. Исходный код, помимо скомпилированных бинарников, и есть результат процесса разработки.
0
Это вы уже додумали. Заказчик мог заплатить за решение задачи. Простой пример, заказали бюст, в процессе изготовление было сделано специальное долото. Для показа бюста долото не нужно. Почему заказчику нужно отдать и инструмент?
Это может и должно оговариваться отдельно.
Это может и должно оговариваться отдельно.
+1
На сколько знаю, если с заказчиком, работодателем или еще кем-то заключается договор, в котором явно это указано, то все, что сделал и изобрел работник во время решении поставленной задачи — принадлежит работодателю.
Но да, вы правы, это должно быть описано в договоре. Плюс такой договор должен быть составлен и подписан.
Но да, вы правы, это должно быть описано в договоре. Плюс такой договор должен быть составлен и подписан.
+1
От договора зависит.
0
Cython, кстати, умеет создавать и исполняемые файлы, а не только библиотеки-модули для импорта. Используя ключ --embed можно обойтись без cx_Freeze.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как обезопасить исходники своего python-приложения