ZerG
количество плюсов при использовании веба зашкаливает!

А набор опыта питона как сюда привязать?

Постоянные обновления сервера, зависимость от железа (что-бы не упало, если не виртуально крутится).

Если бы стояла только задача создать регистрацию почты, то наверняка питон не понадобился бы совсем. Да и разговор не об этом.

Спросил тс про .ехе, я сказал, что это реально. Может для большинства это и не нужно, но рабочая возможность есть.

Да и еще, вопрос тем, кто советуют ставить питон на каждый комп. В проге используется несколько сторонних модулей, типа PyQt, для экселя, для отправки сообщений и прочего. Это тоже придется ставить на каждый комп, это вы учли? В экзешнике же уже все учтено, он полностью ни от чего не зависит. Или взять пример игры, экзешник запустил и играешь (какие-нибудь танчики/марио, если кто-нибудь еще в такое играет), в противном случае опять же придется ставить много сторонних пакетов, что не есть удобно, учитывая, что разные пакеты не всегда на всех версиях питона работают.

А набор опыта питона как сюда привязать?

Как это куда? Логика вся на питоне! Разница только в том что вы для написания ГУИ интерфейса использовали граф библиотеку а тут веб. И все это так же делается на питоне.

Постоянные обновления сервера, зависимость от железа (что-бы не упало, если не виртуально крутится).

Какая зависимость? Вы о чем? Один раз подняли веб сервер и забыли. Работает и кушать не просит.

Если бы стояла только задача создать регистрацию почты, то наверняка питон не понадобился бы совсем. Да и разговор не об этом.

Тут совсем не понял мысль.

Спросил тс про .ехе, я сказал, что это реально. Может для большинства это и не нужно, но рабочая возможность есть.

Есть, ровно как и клепать из кода app для мака и пакеты для линукса.

Да и еще, вопрос тем, кто советуют ставить питон на каждый комп. В проге используется несколько сторонних модулей, типа PyQt, для экселя, для отправки сообщений и прочего. Это тоже придется ставить на каждый комп, это вы учли? В экзешнике же уже все учтено, он полностью ни от чего не зависит. Или взять пример игры, экзешник запустил и играешь (какие-нибудь танчики/марио, если кто-нибудь еще в такое играет), в противном случае опять же придется ставить много сторонних пакетов, что не есть удобно, учитывая, что разные пакеты не всегда на всех версиях питона работают.

Ставить для работы программы питон на каждый комп есть идиотизм в разрезе клиентского приложения. По сему и был предложен вариант с вебмордой - который исклчает понятие написание клиентской части в принцыпе. Клиенту нужен только браузер. Все - он готов работать!

ZerG
По сему и был предложен вариант с вебмордой - который исклчает понятие написание клиентской части в принцыпе. Клиенту нужен только браузер. Все - он готов работать!

Да я и не спорю, что с веб результат, наверняка, был бы лучше.

Проблема была в том, что до написания гуи-приложения у меня было 6 недель опыта в консольных приложениях и в программировании вообще. Написаль консольную регистрацию почты, но, ожидаемо, не понравилось, попросили привычную графическую. Пришлось в очень быстром темпе изучать ООП, гуи, sql запросы, с чем прежде вообще не сталкивался.

Может потом и переделаю в веб приложение, но на тот момент выбор пал на полностью независимое, переносное решение, что в итоге и получилось.

Получен ценный опыт, который можно применять в других проектах.

ZerG
Тут совсем не понял мысль.

Я к тому, что если бы стояла задача написать программу регистрации почты, наверняка это было бы сделано другими средствами (есть на фирме программеры, а я обычный админ, подумывающий о смене профессии).
Тут я сам пришел к тётям и спросил, есть ли какие-нибудь задачи, что можно автоматизировать, чтобы и опыта набраться и польза фирме была, вот тогда и прозвучала мысль, сделать удобную регистрацию посылок (используя сканнер баркодов), вместо записи ручкой в журнале.

Если все так плохо с экзешниками, то для чего столько пакетов написали (cx_freeze, py2exe, pyinstaller, nuitka и прочее)? Кто-то же пользуется этой возможностью.

ZerG
Есть, ровно как и клепать из кода app для мака и пакеты для линукса.

Ну, не знаю, как в других фирмах, у нас 99% это компы с виндой, под это и писалось.

ZerG
Ставить для работы программы питон на каждый комп есть идиотизм в разрезе клиентского приложения

Это не идиотизм, это экстремизм.

Puten
Этот пункт не понял. У меня сама программа создает файлик БД, если его нету и все туда записывает.

Имелось ввиду что безразлично как делать a.py вызвать или a.exe логика работы с базой у них одинаковая. поэтому разницы в том что на сервере положить.

Puten
Бери на усбшку и в другом месте используй. С веб сервером такое не прокатит.

Вы сильно заблуждаетесь. Можно и веб сервер на флешку записать, и одним кликом запустить web приложение и браузер. Никакой разницы нет.

Puten
установке на каждый комп питона, вместо ссылки на прогу, которая места не занимает, не нашел

Вы наверное плохо представляете что делает ваш изготовитель exe. Он тупо пакует питон и нужные библиотеки в исполняемый файл. Этот вариант эквивалентен установке питона в разделяемую папку. Просто питон будет не одним файлом а набором файлов. И в случае если вы сделаете вторую программу то у вас на сервере будет 2 питона а не один. В результате места по мере развития ваших программистских навыков будет как раз заниматься гораздо больше.

Еще один аргумент

Puten
У пользователей нету прав на установку софта, поэтому учить их установке не нужно. Пришел админ и тем, кому надо, сделал ссылку

Ссылку можно с равным успехом сделать и на python.exe в сетевой папке.

Puten
Тем более, что больше питон на этих компах больше ни для чего не будет нужен.

Puten
но все пожелания уже учтены и пользователи больше ничего добавлять/убирать не хотят

Я честно пытался прикинуть будет ваш подход лучше для людей которые за всю свою жизнь напишут одну единственную программу, только для windows и никогда не будут ее менять. Но и в этом случае я думаю что он хуже.

Puten
Так что пока извините, не убедили

Вы попросили оценить ваш подход. Я постарался ответить поподробнее поскольку для новичков характерна попытка превратить скрипт в исполняемый файл. На мой взгляд это некоторая костность мышления.

• Легкость для пользователя установки приложения. Разницы нет, После работы админа пользователь просто тыкает в появившийся ярлык.
  
• легкость создания дистрибутива. В одном случае копирование питона и приложения на сервер в другом компиляция exe и копирование на сервер. Разницы в трудоемкости нет.
  
• Модернизация и поддержка приложения. Очевидно скрипт модернизировать проще.
  
• Занимаемое дисковое пространство. exe вариант хуже если приложений более чем одно.
  
• Надежность. Вариант с exe более стабилен к модернизациям (копия питона внутри).
  
• Возможность изготовления портабельной версии на флешке. Разницы нет.
  
• кросплатформенность, переносимость x64->x32 у exe варианта отсутствует.
  
• вирусоустойчивость. У exe варианта хуже.
  

Помоему объективные аргументы кончились.

Пусть люди смотрят и принимают решение.

Остался аргумент
На виндовские сервера тоже не хочется ставить питон.
Это уже субъективно. Кому что нравится… Я люблю ставить на сервера питон, но не люблю ставить MS Office. :)

doza_and
Помоему объективные аргументы кончились.

Ещё есть скрипты на втором и скрипты на третьем. Тогда python.exe начинает ссылаться на последний установленый. И если где-то есть куча ярлыков на python.exe, то установка другой версии питона их сломает.

py.user.next
И если где-то есть куча ярлыков на python.exe,

Если в ярлыке прописан полный путь к питону как он сломается? Если питон снести или напихать в него конфликтующих пакетов то да, не будут работать скрипты. Это то что я имел ввиду в пункте надежность.

Хотя может вы и правы. Мы вообще ярлыками не пользуемся на виндовых машинах. Скрипты и программы мы никогда не запускаем тыча мышкой. Поэтому опыта у нас в этом маловато.

doza_and
Если в ярлыке прописан полный путь к питону как он сломается?

Не, там ярлык делается на сам скрипт. У меня так есть скрипт парковки/перезагрузки и на него сделаны два разных ярлыка: один запускает его, вызывая паркову; другой запускает его, вызывая перезагрузку. Потом эти ярлыки помещены в пуск, а потом у них настроены хоткеи в свойствах на Ctrl + Alt + h и Ctrl + Alt + r. (Если в пуск не поместить, хоткеи не будут работать.) Таким образом у меня сделана парковка и перезагрузка по хоткеям на ярлыки, использующие один скрипт на питоне. А кликать, я их не кликаю никогда.

При установке же .py и .pyw файлы ассоциируются по новой.

doza_and
Имелось ввиду что безразлично как делать a.py вызвать или a.exe логика работы с базой у них одинаковая. поэтому разницы в том что на сервере положить.

Ваше решение - установка питона на один из серверов + все нужные пакеты и ссылку на .py клиентам?
Такой вариант более приемлем, чем на каждый комп ставить питон + все пакеты, каждый раз разные для разного софта.

Из минусов, ассоциации с .py файлами. Т.к. на клиентах нету питона, нужно указывать питон на сервере. Руками на каждом клиенте? (может и можно политикой прописать). Если слетит ассоциация (из-за обновлений или еще чего), то снова выставлять ручками.

Плюс, из-за того, что .py можно любым блокнотом открыть, то скрипт никак не защищен от глупости пользователя. Если убрать права на запись, то, возможно, не будет возможности сохранять данные в БД (не тестировал). Как по мне, так минусов тоже хватает.

doza_and
Вы сильно заблуждаетесь. Можно и веб сервер на флешку записать, и одним кликом запустить web приложение и браузер. Никакой разницы нет.

Не буду спорить, опыта в переносных веб серверах нету.

doza_and
Вы наверное плохо представляете что делает ваш изготовитель exe. Он тупо пакует питон и нужные библиотеки в исполняемый файл. Этот вариант эквивалентен установке питона в разделяемую папку. Просто питон будет не одним файлом а набором файлов. И в случае если вы сделаете вторую программу то у вас на сервере будет 2 питона а не один. В результате места по мере развития ваших программистских навыков будет как раз заниматься гораздо больше.

Хорошо представляю, что из чего состоит собранный ехе, тем более, в доках про это написано.
Про “много программ - много места”, тут тоже соглашусь. Если в итоге будет несколько десятков программ, то 1 питон + много скриптов займут намного меньше места, чем куча упакованных питонов.

doza_and
кросплатформенность, переносимость x64->x32 у exe варианта отсутствует.

x64 -> x32 решил использованием x32 версии питона, ехе работает и на 64 и на 32.

Кроссплатформенность… Если уж совсем кому-то нужно будет на маке или лине запустить, можно дать человеку скрипт, пусть его запускает, только пути к БД поменять и будет все работать.

Спасибо за критику.

Puten
Хорошо представляю, что из чего состоит собранный ехе, тем более, в доках про это написано.

А Вы не доки почитайте, Вы посмотрите что там в pyinstaller внутри. Мы уже на нем обожглись конкретно. Планировали с высокоуважаемым JOHN_16 сделать цикл статей, а как начали копаться так прозрели вообще полностью. Я не писал, что exe это зло, это и так понятно, но раз хочется делать пакеты, которые не везде и не всегда будут запускаться (не видел кроссплатформенного решения пока даже для всех вЫндовзов), то лучше тогда использовать cxFreeze. Как-то так.

Puten
Ваше решение - установка питона на один из серверов + все нужные пакеты и ссылку на .py клиентам?

Зачем ссылки на .py??? В вебне???