Какие-то смешанные чувства от приводимых примеров.
Mutable default - отличный подвох, неоднократно подсвечивал его на кодревью, и пару раз чинил баги когда оно сквозь кодревью просачивалось.
Comprehensions - тоже понять можно, фича с подвохом, доводилось и этажерки сворачивать в однострочники, и наоборот, все во имя читаемости.
55, ==, is - чёрт его знает, я бы на собеседовании в качестве правильного ответа принимал "надо смотреть порядок операций" и "не знаю, страшно, разворот на кодревью и принудительная расстановка скобок".
Хэшируемость ключей в словарях - ну... у меня есть интерпретатор, линтеры, статические анализаторы и тесты; благодаря этому всему я уже сам не помню, какое именно условие накладывается на ключи и что там хэшируется по умолчанию, что нет, и где (не)работает транзитивность оного хэширования.
Ромбовидное наследование - офигеть, а в питоне это есть? Круто, надо бы запретить по возможности, в плюсах от этого сплошная головная боль была!
Не питон-разработчик, не автотестер, не девопс, просто последние лет 5 часто на нём пишу все подряд. Моя база по питону 100% будет отличаться от базы дата-сатанистов и веб-разработчиков.
Для себя решал проблему через EarlyOOM. Переконпелировать ведро с васянскими патчами - это выше моего уровня, но про MGLRU узнать было интересно, спасибо; надо будет попробовать поиграться с чиселками в /sys/...
Писатель часто говорил и об опасности заигрываний с мессианством и религиозным фанатизмом: увы, эта тема в первой книге раскрыта недостаточно полно. У протагониста нет особых сомнений и опасений по поводу выпуска из бутылки джинна священной войны.
Простите, но нет. Я пошёл перечитывать книгу как раз после обоих фильмов разом - и вот как раз в книге Пол вполне себе регулярно терзается мыслями о том, что куда ни поверни - кругом предпосылки к джихаду, и чем дальше в пустыню - тем сильнее сужается круг возможностей.
А в целом статья хорошая, лучше фильмов :D Хотя фильмы, особенно в отрыве от первоисточника, тоже балдёжные.
Статья интересная, но не могу удержаться от дилетантского вопроса. Неужели вся эта инженерная работа стоит дешевле, чем просто загонять на крышу тех же самых уборщиков снега просто спустя день/полдня/двадня после того, как пошёл снег? Вот буквально по принципу "крышу стало не видно".
В середине 2000х выходила отечественная стратегия Maelstrom, где человеки сражались с пришельцами, которые прилетели затопить планету. Вода использовалась как ресурс и как средство ведения боя - планетяне затапливали всё кругом и имели юниты получающие бонус от нахождения в воде, а людские танки в воде глохли, и нужно было бульдозерами засыпать лужи обратно. Всё это с терраформингом и динамическим распределением воды по карте - можно было срыть берег у горного озера и устроить потоп в долине. Игра была кривущщщая, аж жуть, но весёлая.
Пока читал и смотрел картинки - не покидало ощущение, что где-то я видел уже что-то эдакое... а потом дело дошло до "зелёных глаз" - и всё сразу встало на свои места; я же видел эту демку о одного стримера на твиче!) Спасибо за статью, хороший слог и любопытная история (хоть и местами упоротая). Жанр и стиль игры - и максимально не моё, но от души желаю удачи на этом поприще.
Земной поклон за такой труд! Уточню на всякий случай: в плейлисте на ютубе 69 видео, вводная + уроки от 0 до 66; судя по номерам ничего не потерялось - но ютуб пишет 1 unavailable video is hidden. За кадром осталось что-то тестовое?
Давайте я тоже вместе с вами позанудствую, поскольку я и сам не встречал реальной необходимости в перечисленных вещах (ну кроме рекурсии).
Суть не в том, что ежедневная работа будет заключаться в переизобретении сортировок. Суть в том, что это хорошая вводная к практической части собеса.
Своп встречается чуть ли не в каждом первом случае и делается за полторы минуты, если вообразить в голове инвентарь из компьютерной игры, в котором предметы перекладываются туда-сюда — а потом аккуратно печатать по одной букве смотря на клавиатуру — преодолевая при этом дикий стресс от собеседования. Если кандидат медленно печатает и/или застрял (таких было трое) — у меня проблемы, надо на ходу перекраивать объём дальнейшего опросника.
Факториалом можно проверить знание сразу и функций, и циклов, и рекурсии. Определение факториала я даю сразу вместе с задачей, злостных пометок "не знает что означает нотация 6!, не учился, двойка" в книжечке не делаю — как и пометок про незнание рекурсии.
Фибоначчи — замечательная проверка на (не)знание генераторов в Питоне. Определение тоже даю, незнание генераторов тоже в книжечку косяков не заносится — вместо этого я лучше сам в двух словах объясню, зачем они нужны.
Сортировка — прекрасная возможность сказать "а вот в стандартной библиотеке есть метод..." и кокетливо посмотреть на "собеседника". Сам так отвечал во всех случаях, когда мне на собесе задавали этот вопрос. Если так ответить мне — сердечко сделает "тук-тук!", глаза загорятся, я в ответ спрошу чем отличается sorted(list) от list.sort(), и мы сольёмся в страстных объятьях спора о том, почему императивное программирование лучше функционального. Если возможность упущена — писать сортировку я даже не прошу; но спрашиваю, знает ли кандидат вообще, что они бывают разные.
Кандидат нещадно тупит? Повод аккуратно поинтересоваться, всё ли нормально. Может у него кошка умерла, тогда его надо отпустить с миром и попробовать ещё раз через недельку. Кандидат не знает что сказать? Держим ушки на макушке и идём дальше. Кандидат строчит как пулемёт и всё как от зубов отскакивает? Отлично же! Кандидат откровенно цитирует справочник, википедию и документацию? Да и пусть! Ведь после этого я в любом случае перехожу к настоящим вопросам — про argparse из стандартной библиотеки, про contextlib оттуда же, про установку дополнительных пакетов, использование виртуальных окружений, линтеры, фреймворки, логирование, тестирование и так далее. Если мне повезло — я потратил 5 минут и мы несёмся галопом по европам дальше. Если не повезло — я аккуратно выбираю, чем мне ещё прощупать почву.
В конце 2019го решили расширять нашу команду внутренней автоматизации — сущий винегрет и фарш из технологий, + много Python. Питон буквально стоял в требованиях к вакансии, потому что его у нас прям много в самых разных формах. И вот тимлид тогда регулярно жаловался, что у него на собеседованиях не получается дойти до "профильных" вопросов по питону, потому что приходят люди, не умеющие значения двух переменных поменять местамии. "Они не знают про кортежи?" — удивлялся я. "Они не знают про tmp=a; a=b; b=tmp!" — сокрушался тимлид...
Я думал, это какое-то преувеличение или сбой со стороны рекрутёров. Но затем в 2023, уже в другой конторе в другой стране, я помогал проводить собеседования на такую же должность — и да, действительно! Откликается человек, в резюме бакалавриат (иногда даже по CS/SE!), 2-3 года работы junior+ в 1-2 компаниях, "knowledgeable in python", куча умных терминов и сокращений. Начинается собес, вроде норм, доходим до практической части. Значения переменным присваивать — пожалуйста, "swap two variables" — громкий скрип шестерёнок, факториал — тишина, спарсить параметры командной строки через стандартный модуль argparse — откровенное непонимание в глазах. Самое смешное получалось, когда задаваемый вопрос был больше справочно-теоретического характера или из тех, что упоминаются в каждой статье "как подготовиться к собесу", — тогда даже самый бессвязный кандидат мог выпалить ответ как из пушки, не задумываясь ни на полминуты...
(На должность в итоге взяли паренька с дипломом инженера-авиаконструктора, который питон учил несколько месяцев на каких-то летних курсах при своём универе, на собесе регулярно признавался "не помню/не знаю, можно в гугл?", листал пару вопросов на SO, и выдавал ответы приближённые к реальности — потому что решили, что ну нафиг искать кого-то профитного, возьмём вот этого смышлённого, доучим на месте. Пока ещё ни разу не пожалели)
Да, он написан на питоне, а не на расте, но на что только не пойдёшь ради чистого и собирающегося кода, можно даже переквалифицироваться из питон-разработчка в раст-разработчика. Делаем pre-commit install - это создаёт хук .git/hooks/pre-commit, который будет впоследствии автоматически запускать pre-commit run на изменённые файлы. Делаем pre-commit sample-config > .pre-commit-config.yaml - это создаёт конфиг с набором дефолтных хуков, которыми pre-commit "из коробки" готов проверять изменённые файлы:
trailing-whitespace будет ругаться на строчки, оканчивающиеся пробелами, и эти пробелы стирать. Полезно, потому что не во всех редакторах это включено по-умолчанию, или вообще присутствует как класс.
end-of-line-fixer будет ругаться, если в каком-то файле забыли добавить \n в конец (привет винда!), или наоборот насовали слишком много \n\n\n\n - и тоже добавлять-стирать нужное.
check-yaml будет проверять изменённые в коммите YAML-файлы на синтаксическую корректность.
check-added-large-files будет давать по шапке за попытку закоммитить в репозиторий бинарный суп на 10+ мегабайт - для такого боги даровали нам Git-LFS, Artifactory, Nexus или простихоспаде файлопомойки вроде SFTP/NFS/SMB.
Если хочется ещё - можно докинуть в список, например, check-merge-conflict - оно не даст случайно добавить в коммит "сломаный" после неудачного мержа файл с кучей >>> === <<<. Если что-то кажется лишним - можно убрать.
2. Подключаем "плагин" для проверки проектов на Rust.
На изкоробочном функционале далеко не уедешь - да это и не требуется, поскольку pre-commit рассчитан на активное переиспользование чужого кода с гитхаба:
(содержимое репозитория pre-commit-rust настолько тривиально, что его можно было бы переписать с нуля - но пока более интересна сама возможность с лёгкостью притащить чужое)
Чем это отличается от описанного в статье (помимо отсутствия cargo test)? Тремя важными нюансами:
pre-commit работает только с изменениями, претендующими на коммит. Если часть изменений в main.rs добавлена в staged, а часть нет - из-за интерактивного git add, или вы просто дописали в файл что-то новенькое после стейджа - pre-commit автоматически спрячет "лишнее" через git stash. Это позволяет избежать дурацких ситуаций, когда текущий файл сам по себе норм - но в стейдж например забыли добавить блок с новой функцией.
Автор в хуке делает леденящее cargo fmt && git add ., которое не только похерит возможность использования git add --interactive (как уже писали выше), но и будет добавлять в коммит остальные файлы из рабочей директории, даже если вы их не помечали через git add. В свою очередь, pre-commit после git stash считает хук провалившимся как если он вернул ненулевой код, так и если после работы хука в репозитории появились not staged файлы - это именно то, что мы имеем с cargo fmt.
Большая часть хуков в pre-commit срабатывают только на изменённые файлы определённого типа. Так, хук fmt дёргает cargo fmt -- <changed rust files>: это означает, что во-первых, если форматирование поехало где-то в другой части проекта, ложно-положительных ошибок мы не получим, а во-вторых, если в коммите не трогается код на расте (а например редактируется сугубо README.md - то и растовские хуки срабатывать не будут. Справедливости ради, cargo check и cargo clippy не имеют режима анализа только одного файла - так что с ними проверка будет "полная".
3. Добавляем в pre-commit собственные хуки.
Если нам позарез хочется перед каждым коммитом запускать тесты, выполнять полноценную сборку, вызывать сотону или делать другие нестандартные вещи - pre-commit вполне поддерживает написание собственных хуков:
- repo: local
hooks:
- id: cargo-test
name: run Rust tests
description: Why not?
entry: cargo test
language: system
types: [rust]
pass_filenames: false
Хоп, и теперь он будет вызывать содержимое entry как обычный процесс (благодаря language=system) всякий раз, когда в потенциальном коммите изменяются rust-файлы. Вместо types: [rust] можно также указать files: <regex>. По умолчанию pre-commmit передаёт в хук пути до изменённых файлов - но в нашем случае cargo test some/changed/file.rs просто скажет, что running 0 tests, test result: ok. 0 passed; 0 failed; 3 filtered out; поэтому мы велим вызывать команду как она есть, не скармливая в неё файлы. Аналогично можно будет запускать какой-нибудь самописный tools/linter.sh, который припасён у вас в репозитории.
Большинство плагинов для pre-commit пишутся из расчёта на то, чтобы вызываться pre, собственно, commit - но сама тулза поддерживает ещё и pre-rebase, pre-push и так далее. Если у вас слишком много тестов, их можно вызывать только перед пушем - для этого в описание хука надо добавить stages: [push] (работает и для изкоробочных, и для сторонних, и для локальных хуков), а в самое начало конфига рядом с repos: - добавить default_install_hook_types: [pre-commit, pre-push] и вызвать pre-commit install ещё разок.
4. Добавляем pre-commit в CI.
Хуки в гите работают на доверии и добровольческой основе. Любой зашедший с улицы Васян после git clone получит чистую папку .git/hooks/ и сможет радостно коммитить несобирающийся код с лишними пробелами и переносами строк. И даже если пан Васян соизволят вызвать у себя pre-commit install для инициализации .git/hooks/pre-commit, это не помешает им позже сказать "у меня лапки!" и сделать git commit --no-verify, послав далеко и надолго простыню непонятных ошибок. Едиинственное, что остановит Васяна - разработка через пулл-реквесты и правильно настроенная система Continuous Integration.
Самый простой вариант - иметь один и тот же набор проверок и "на клиенте" и "на сервере". Благо pre-commit может запускаться не только на списке файлов из staged, но и на всех файлах целиком pre-commit run --all-files), и даже на изменённых файлах из указанного промежутка между коммитами (pre-commit run --from-ref=... --to-ref=.... На условном Github Actions это можно сделать так:
name: pre-commit
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
env:
CARGO_TERM_COLOR: always
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: pre-commit linters
run: |
set -ex
pip install pre-commit
# github does not have branch names, but BASE_REF is a name, not a commit SHA
git fetch
if [ -n "$GITHUB_BASE_REF" ]; then
# this is a PR - check only changed files
pre-commit run \
--verbose \
--show-diff-on-failure \
--from-ref=${{ github.event.pull_request.base.sha }} \
--to-ref=${{ github.event.pull_request.head.sha }}
else
# this is a push to main - check everything
pre-commit run \
--verbose \
--show-diff-on-failure \
--all-files
fi
Это не значит, что ваш CI всегда должен плясать от pre-commit; о "правильной настройке" CI, особенно на больших проектах, можно вообще писать статьи и книги. Просто любая автоматизация проверок будет лучше, чем никакой автоматизации.
В поддержку podsvirov, ответ одного из разработчиков симейка:
It is worth pointing out that many of the findings are actually the in 3rd-party libraries libuv, libcurl, rhash, and libarchive. Especially the last one seems to contribute many issues. You might want to analyze this one next?
The remaining issues come from CTest, CPack, and the Visual Studio specific code. I am surprised the the core of CMake is actually pretty clean.
Это же просто чиселка, на которую можно ориентироваться, да? Вы же не хотите сказать, что если бы мне через неделю стукнуло 24, то дешёвый билет я бы купить не смог, при абсолютной их идентичности?
Какие-то смешанные чувства от приводимых примеров.
Mutable default - отличный подвох, неоднократно подсвечивал его на кодревью, и пару раз чинил баги когда оно сквозь кодревью просачивалось.
Comprehensions - тоже понять можно, фича с подвохом, доводилось и этажерки сворачивать в однострочники, и наоборот, все во имя читаемости.
55, ==, is - чёрт его знает, я бы на собеседовании в качестве правильного ответа принимал "надо смотреть порядок операций" и "не знаю, страшно, разворот на кодревью и принудительная расстановка скобок".
Хэшируемость ключей в словарях - ну... у меня есть интерпретатор, линтеры, статические анализаторы и тесты; благодаря этому всему я уже сам не помню, какое именно условие накладывается на ключи и что там хэшируется по умолчанию, что нет, и где (не)работает транзитивность оного хэширования.
Ромбовидное наследование - офигеть, а в питоне это есть? Круто, надо бы запретить по возможности, в плюсах от этого сплошная головная боль была!
Не питон-разработчик, не автотестер, не девопс, просто последние лет 5 часто на нём пишу все подряд. Моя база по питону 100% будет отличаться от базы дата-сатанистов и веб-разработчиков.
Для себя решал проблему через EarlyOOM. Переконпелировать ведро с васянскими патчами - это выше моего уровня, но про MGLRU узнать было интересно, спасибо; надо будет попробовать поиграться с чиселками в
/sys/...Простите, но нет. Я пошёл перечитывать книгу как раз после обоих фильмов разом - и вот как раз в книге Пол вполне себе регулярно терзается мыслями о том, что куда ни поверни - кругом предпосылки к джихаду, и чем дальше в пустыню - тем сильнее сужается круг возможностей.
А в целом статья хорошая, лучше фильмов :D Хотя фильмы, особенно в отрыве от первоисточника, тоже балдёжные.
Статья интересная, но не могу удержаться от дилетантского вопроса. Неужели вся эта инженерная работа стоит дешевле, чем просто загонять на крышу тех же самых уборщиков снега просто спустя день/полдня/двадня после того, как пошёл снег? Вот буквально по принципу "крышу стало не видно".
В середине 2000х выходила отечественная стратегия Maelstrom, где человеки сражались с пришельцами, которые прилетели затопить планету. Вода использовалась как ресурс и как средство ведения боя - планетяне затапливали всё кругом и имели юниты получающие бонус от нахождения в воде, а людские танки в воде глохли, и нужно было бульдозерами засыпать лужи обратно. Всё это с терраформингом и динамическим распределением воды по карте - можно было срыть берег у горного озера и устроить потоп в долине.
Игра была кривущщщая, аж жуть, но весёлая.
Пока читал и смотрел картинки - не покидало ощущение, что где-то я видел уже что-то эдакое... а потом дело дошло до "зелёных глаз" - и всё сразу встало на свои места; я же видел эту демку о одного стримера на твиче!) Спасибо за статью, хороший слог и любопытная история (хоть и местами упоротая). Жанр и стиль игры - и максимально не моё, но от души желаю удачи на этом поприще.
Земной поклон за такой труд!
Уточню на всякий случай: в плейлисте на ютубе 69 видео, вводная + уроки от 0 до 66; судя по номерам ничего не потерялось - но ютуб пишет 1 unavailable video is hidden. За кадром осталось что-то тестовое?
Давайте я тоже вместе с вами позанудствую, поскольку я и сам не встречал реальной необходимости в перечисленных вещах (ну кроме рекурсии).
Суть не в том, что ежедневная работа будет заключаться в переизобретении сортировок. Суть в том, что это хорошая вводная к практической части собеса.
Своп встречается чуть ли не в каждом первом случае и делается за полторы минуты, если вообразить в голове инвентарь из компьютерной игры, в котором предметы перекладываются туда-сюда — а потом аккуратно печатать по одной букве смотря на клавиатуру — преодолевая при этом дикий стресс от собеседования. Если кандидат медленно печатает и/или застрял (таких было трое) — у меня проблемы, надо на ходу перекраивать объём дальнейшего опросника.
Факториалом можно проверить знание сразу и функций, и циклов, и рекурсии. Определение факториала я даю сразу вместе с задачей, злостных пометок "не знает что означает нотация
6!, не учился, двойка" в книжечке не делаю — как и пометок про незнание рекурсии.Фибоначчи — замечательная проверка на (не)знание генераторов в Питоне. Определение тоже даю, незнание генераторов тоже в книжечку косяков не заносится — вместо этого я лучше сам в двух словах объясню, зачем они нужны.
Сортировка — прекрасная возможность сказать "а вот в стандартной библиотеке есть метод..." и кокетливо посмотреть на "собеседника". Сам так отвечал во всех случаях, когда мне на собесе задавали этот вопрос. Если так ответить мне — сердечко сделает "тук-тук!", глаза загорятся, я в ответ спрошу чем отличается
sorted(list)отlist.sort(), и мы сольёмся в страстных объятьях спора о том, почему императивное программирование лучше функционального.Если возможность упущена — писать сортировку я даже не прошу; но спрашиваю, знает ли кандидат вообще, что они бывают разные.
Кандидат нещадно тупит? Повод аккуратно поинтересоваться, всё ли нормально. Может у него кошка умерла, тогда его надо отпустить с миром и попробовать ещё раз через недельку.
Кандидат не знает что сказать? Держим ушки на макушке и идём дальше.
Кандидат строчит как пулемёт и всё как от зубов отскакивает? Отлично же!
Кандидат откровенно цитирует справочник, википедию и документацию? Да и пусть!
Ведь после этого я в любом случае перехожу к настоящим вопросам — про argparse из стандартной библиотеки, про contextlib оттуда же, про установку дополнительных пакетов, использование виртуальных окружений, линтеры, фреймворки, логирование, тестирование и так далее. Если мне повезло — я потратил 5 минут и мы несёмся галопом по европам дальше. Если не повезло — я аккуратно выбираю, чем мне ещё прощупать почву.
А вы как собеседуете?
Автору лучи поддержки и понимания.
В конце 2019го решили расширять нашу команду внутренней автоматизации — сущий винегрет и фарш из технологий, + много Python. Питон буквально стоял в требованиях к вакансии, потому что его у нас прям много в самых разных формах. И вот тимлид тогда регулярно жаловался, что у него на собеседованиях не получается дойти до "профильных" вопросов по питону, потому что приходят люди, не умеющие значения двух переменных поменять местамии. "Они не знают про кортежи?" — удивлялся я. "Они не знают про
tmp=a; a=b; b=tmp!" — сокрушался тимлид...Я думал, это какое-то преувеличение или сбой со стороны рекрутёров. Но затем в 2023, уже в другой конторе в другой стране, я помогал проводить собеседования на такую же должность — и да, действительно! Откликается человек, в резюме бакалавриат (иногда даже по CS/SE!), 2-3 года работы junior+ в 1-2 компаниях, "knowledgeable in python", куча умных терминов и сокращений. Начинается собес, вроде норм, доходим до практической части. Значения переменным присваивать — пожалуйста, "swap two variables" — громкий скрип шестерёнок, факториал — тишина, спарсить параметры командной строки через стандартный модуль
argparse— откровенное непонимание в глазах.Самое смешное получалось, когда задаваемый вопрос был больше справочно-теоретического характера или из тех, что упоминаются в каждой статье "как подготовиться к собесу", — тогда даже самый бессвязный кандидат мог выпалить ответ как из пушки, не задумываясь ни на полминуты...
(На должность в итоге взяли паренька с дипломом инженера-авиаконструктора, который питон учил несколько месяцев на каких-то летних курсах при своём универе, на собесе регулярно признавался "не помню/не знаю, можно в гугл?", листал пару вопросов на SO, и выдавал ответы приближённые к реальности — потому что решили, что ну нафиг искать кого-то профитного, возьмём вот этого смышлённого, доучим на месте. Пока ещё ни разу не пожалели)
Что такое коропративный доступ к вскоду?
Как его заблокируют?
Без сарказма, мне реально любопытно.
Начинание отличное, но зачем же останавливаться на полпути? ?
1. Берём pre-commit.
Да, он написан на питоне, а не на расте, но на что только не пойдёшь ради чистого и собирающегося кода,
можно даже переквалифицироваться из питон-разработчка в раст-разработчика.Делаем
pre-commit install- это создаёт хук.git/hooks/pre-commit, который будет впоследствии автоматически запускатьpre-commit runна изменённые файлы.Делаем
pre-commit sample-config > .pre-commit-config.yaml- это создаёт конфиг с набором дефолтных хуков, которымиpre-commit"из коробки" готов проверять изменённые файлы:trailing-whitespaceбудет ругаться на строчки, оканчивающиеся пробелами, и эти пробелы стирать. Полезно, потому что не во всех редакторах это включено по-умолчанию, или вообще присутствует как класс.end-of-line-fixerбудет ругаться, если в каком-то файле забыли добавить\nв конец (привет винда!), или наоборот насовали слишком много\n\n\n\n- и тоже добавлять-стирать нужное.check-yamlбудет проверять изменённые в коммите YAML-файлы на синтаксическую корректность.check-added-large-filesбудет давать по шапке за попытку закоммитить в репозиторий бинарный суп на 10+ мегабайт - для такого боги даровали нам Git-LFS, Artifactory, Nexus или простихоспаде файлопомойки вроде SFTP/NFS/SMB.Если хочется ещё - можно докинуть в список, например,
check-merge-conflict- оно не даст случайно добавить в коммит "сломаный" после неудачного мержа файл с кучей>>> === <<<.Если что-то кажется лишним - можно убрать.
2. Подключаем "плагин" для проверки проектов на Rust.
На изкоробочном функционале далеко не уедешь - да это и не требуется, поскольку pre-commit рассчитан на активное переиспользование чужого кода с гитхаба:
(содержимое репозитория
pre-commit-rustнастолько тривиально, что его можно было бы переписать с нуля - но пока более интересна сама возможность с лёгкостью притащить чужое)Чем это отличается от описанного в статье (помимо отсутствия
cargo test)? Тремя важными нюансами:pre-commit работает только с изменениями, претендующими на коммит. Если часть изменений в
main.rsдобавлена в staged, а часть нет - из-за интерактивногоgit add, или вы просто дописали в файл что-то новенькое после стейджа - pre-commit автоматически спрячет "лишнее" черезgit stash. Это позволяет избежать дурацких ситуаций, когда текущий файл сам по себе норм - но в стейдж например забыли добавить блок с новой функцией.Автор в хуке делает леденящее
cargo fmt && git add ., которое не только похерит возможность использованияgit add --interactive(как уже писали выше), но и будет добавлять в коммит остальные файлы из рабочей директории, даже если вы их не помечали черезgit add. В свою очередь, pre-commit послеgit stashсчитает хук провалившимся как если он вернул ненулевой код, так и если после работы хука в репозитории появились not staged файлы - это именно то, что мы имеем сcargo fmt.Большая часть хуков в pre-commit срабатывают только на изменённые файлы определённого типа. Так, хук
fmtдёргаетcargo fmt -- <changed rust files>: это означает, что во-первых, если форматирование поехало где-то в другой части проекта, ложно-положительных ошибок мы не получим, а во-вторых, если в коммите не трогается код на расте (а например редактируется сугубоREADME.md- то и растовские хуки срабатывать не будут. Справедливости ради,cargo checkиcargo clippyне имеют режима анализа только одного файла - так что с ними проверка будет "полная".3. Добавляем в pre-commit собственные хуки.
Если нам позарез хочется перед каждым коммитом запускать тесты, выполнять полноценную сборку, вызывать сотону или делать другие нестандартные вещи - pre-commit вполне поддерживает написание собственных хуков:
Хоп, и теперь он будет вызывать содержимое
entryкак обычный процесс (благодаря language=system) всякий раз, когда в потенциальном коммите изменяются rust-файлы. Вместоtypes: [rust]можно также указатьfiles: <regex>.По умолчанию pre-commmit передаёт в хук пути до изменённых файлов - но в нашем случае
cargo test some/changed/file.rsпросто скажет, чтоrunning 0 tests, test result: ok. 0 passed; 0 failed; 3 filtered out; поэтому мы велим вызывать команду как она есть, не скармливая в неё файлы.Аналогично можно будет запускать какой-нибудь самописный
tools/linter.sh, который припасён у вас в репозитории.Большинство плагинов для pre-commit пишутся из расчёта на то, чтобы вызываться pre, собственно, commit - но сама тулза поддерживает ещё и pre-rebase, pre-push и так далее. Если у вас слишком много тестов, их можно вызывать только перед пушем - для этого в описание хука надо добавить
stages: [push](работает и для изкоробочных, и для сторонних, и для локальных хуков), а в самое начало конфига рядом сrepos:- добавитьdefault_install_hook_types: [pre-commit, pre-push]и вызватьpre-commit installещё разок.4. Добавляем pre-commit в CI.
Хуки в гите работают на доверии и добровольческой основе. Любой зашедший с улицы Васян после
git cloneполучит чистую папку.git/hooks/и сможет радостно коммитить несобирающийся код с лишними пробелами и переносами строк. И даже если пан Васян соизволят вызвать у себяpre-commit installдля инициализации.git/hooks/pre-commit, это не помешает им позже сказать "у меня лапки!" и сделатьgit commit --no-verify, послав далеко и надолго простыню непонятных ошибок. Едиинственное, что остановит Васяна - разработка через пулл-реквесты и правильно настроенная система Continuous Integration.Самый простой вариант - иметь один и тот же набор проверок и "на клиенте" и "на сервере". Благо pre-commit может запускаться не только на списке файлов из staged, но и на всех файлах целиком
pre-commit run --all-files), и даже на изменённых файлах из указанного промежутка между коммитами (pre-commit run --from-ref=... --to-ref=....На условном Github Actions это можно сделать так:
Это не значит, что ваш CI всегда должен плясать от pre-commit; о "правильной настройке" CI, особенно на больших проектах, можно вообще писать статьи и книги. Просто любая автоматизация проверок будет лучше, чем никакой автоматизации.
В поддержку podsvirov, ответ одного из разработчиков симейка:
Это же просто чиселка, на которую можно ориентироваться, да? Вы же не хотите сказать, что если бы мне через неделю стукнуло 24, то дешёвый билет я бы купить не смог, при абсолютной их идентичности?