Один из вариантов, сделать сборку прозрачной. Запихнуть в Докер или GitHub actions. Тогда кто хочет сможет посмотреть на процесс сборки и даже собрать самостоятельно. Тудаже и вирус тотал можно прикрутить. https://github.com/marketplace/actions/virustotal-github-action
Если вы скачиваете Pycharm с сайта JetBrains, то там есть такая строка: Download and verify the file SHA-256 checksum.
PS. У вас очень спецефичная программа с узким набором клиентов, все эти улучшения могут вообще на отразится на колличестве скачиваний.
Вы ухожите от темы, но хорошо что вы вспомнили про разные контексты.
Для меня в статье есть один огромный минус, вы решили проблему в одном контесте и интерполировали выводы на все контексты.
Это а) не правильно, б) вредно.
Если кто-то решит воспользоваться вашим советом и попробует хуки там, где они не к месту то разочаруется в хуках.
Я внутри компании изучаю вопрос более широкого использования хуков и общаюсь с людьми которые их не любят. Часто у них опыт либо там где хуки вообще не стоит пременять или там где сделанно было через одно место.
Я бы сказал одно приложение на один репозиторий с быстрыми хуками это однозначно правильный контест для хуков. В остльных случаях есть нюансы.
У хуков достаточно много проблем, просто авторам повезло на них не попасть.
1) если хуки медленные, то будет неудобно (не все пишут на Питоне) 2) хуки должны быть строгим подмножеством CI, иначе будете чинить чужой код 3) нужно нормально делать сообщения об ошибках (использовать pre-commit), худший случай когда вообще нет вывода в консоль.
Первый и второй шаги я бы пропустил. Для pre-commit уже созданно много готовых хуков. https://pylint.pycqa.org/en/latest/user_guide/installation/pre-commit-integration.html
rsync работает с файлами, а fetch c объектами гита.
Комит в гит не является атомарной операцией на диске, там меняются несколько файлов. В теории при использовании rsync может получиться неконсистениное состояние если вы не останавливаете мастер.
Не всегда стоит матчить целую фразу, можно и часть. В моём примере кстати умышленно отрезана первая часть сообщения, чтобы не создавать излишней привязки к имени класса.
Я петпроекты старюсь где-нибудь хостить в вебе.
Например вот так:
https://extract-vizualization.streamlit.app/
долго просыпается, зато бесплатно.
Один из вариантов, сделать сборку прозрачной. Запихнуть в Докер или GitHub actions. Тогда кто хочет сможет посмотреть на процесс сборки и даже собрать самостоятельно. Тудаже и вирус тотал можно прикрутить. https://github.com/marketplace/actions/virustotal-github-action
Если вы скачиваете Pycharm с сайта JetBrains, то там есть такая строка: Download and verify the file SHA-256 checksum.
PS. У вас очень спецефичная программа с узким набором клиентов, все эти улучшения могут вообще на отразится на колличестве скачиваний.
Процес компиляции не прозрачен. Это что-то что происходит на компьютере пользователя.
С осторожностью.
Вы ухожите от темы, но хорошо что вы вспомнили про разные контексты.
Для меня в статье есть один огромный минус, вы решили проблему в одном контесте и интерполировали выводы на все контексты.
Это а) не правильно, б) вредно.
Если кто-то решит воспользоваться вашим советом и попробует хуки там, где они не к месту то разочаруется в хуках.
Я внутри компании изучаю вопрос более широкого использования хуков и общаюсь с людьми которые их не любят. Часто у них опыт либо там где хуки вообще не стоит пременять или там где сделанно было через одно место.
Я бы сказал одно приложение на один репозиторий с быстрыми хуками это однозначно правильный контест для хуков. В остльных случаях есть нюансы.
Они именно ужасный ужас, для некоторых ситуаций.
Добавьте себе в хуки 1 минуту задержки и попробуйте с этим денёк пожить.
Там где я использую хуки, они у меня хуки быстрые.
У хуков достаточно много проблем, просто авторам повезло на них не попасть.
1) если хуки медленные, то будет неудобно (не все пишут на Питоне)
2) хуки должны быть строгим подмножеством CI, иначе будете чинить чужой код
3) нужно нормально делать сообщения об ошибках (использовать pre-commit), худший случай когда вообще нет вывода в консоль.
Первый и второй шаги я бы пропустил. Для pre-commit уже созданно много готовых хуков.
https://pylint.pycqa.org/en/latest/user_guide/installation/pre-commit-integration.html
Это не миф это реальность. Решаемо.
Только в контексте быстрых хуков.
Дополнительную минуту до комита и много минут после коммита не все захотят ждать. Либо пропустят хуки либо будут комиттить раз в неделю.
Инстукции по установке: Скачайте испольняемый файл и запустите его.
Для меня, это карсный флаг. Даже если у вас нет плохих намерений, то у вас могут быть вирусы, которые прописывают себя в каждый .exe файл.
Это вклад в ваше образование и портфолио. Это полезно.
Я стать про эту задачу уже видел здесь. Но не могу ей найти.
Всё в мире относительно. Монорепы удивлённо поднимаю бровь, а дельфинчики смеются.
Как-то коллега случайно закомитил видео с дельфинчиками размером в 200MB.
rsync работает с файлами, а fetch c объектами гита.
Комит в гит не является атомарной операцией на диске, там меняются несколько файлов. В теории при использовании rsync может получиться неконсистениное состояние если вы не останавливаете мастер.
Я обычно не запускаю скрипт который создаёт страницы, а использую GitHub actions для этого.
Зачем кстати такая страничка нужна?
Можно же просто поместить всё это на свою страницу на GitHub?
Не проще ли сразу полужить туда, для простоты.
Только когда вы начальству продаёте новый внутренний проект.
Не всегда стоит матчить целую фразу, можно и часть. В моём примере кстати умышленно отрезана первая часть сообщения, чтобы не создавать излишней привязки к имени класса.
streamlit по функциональности больше похож на jypiter инструменты, визуализация диаграм.
Он поддерживает базовый UI из коробки. Но когда надо больше, то начинаются проблемы.
И еще streamlit интерактивный. Что с этим у fasthtml я не понял.
Я не большой эксперт в streamlit, так побаловаться.