Обновление (19 сен, 2020)

Наконец-то появился свой сайт! Я переместил все свои статьи на ajmalsiddiqui.me/blog и в процессе этого понял, что сильно вырос с тех пор, как написал эти статьи. Поэтому я буду обновлять статьи, чтобы отражать то, что я узнал, исправлять ошибки и улучшать качество, насколько это возможно. Но все эти обновления будут в первую очередь на моем сайте, поэтому, пожалуйста, прочтите там эту статью. Чао!

В первой статье я представил точечные файлы. В этой статье мы рассмотрим их развитие и управление.

Примечание. Это вторая статья из серии, в которой обсуждаются более сложные аспекты управления точечными файлами. Чтобы узнать, что такое точечные файлы и самые основы управления точечными файлами, прочтите первую статью.

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

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

Настройка вашей среды

Начните с создания каталога для ваших точечных файлов и cd в него. Мне нравится, когда мой находится в папке Projects в моем домашнем каталоге, но это зависит от вас:

$ mkdir ~/Projects/dotfiles
$ cd ~/Projects/dotfiles

Здесь у нас будут все наши точечные файлы. Начнем с создания репозитория git.

$ git init

Начнем с перемещения .bash_profile из каталога HOME в наш новый каталог точечных файлов.

$ mv ~/.bash_profile ~/Projects/dotfiles/.bash_profile

Давайте зафиксируем этот файл.

$ git commit -am "Added .bash_profile"

И вот оно! Именно так вы бы работали над любым другим проектом, и именно так вы должны управлять своими точечными файлами.

Можно спросить, зачем нужен контроль версий. Людям нравится передавать свои точечные файлы в систему контроля версий по нескольким причинам:

  • Отправка точечных файлов в удаленное репо позволяет людям делиться своими точечными файлами с другими или получать к ним удаленный доступ, когда они им нужны. Это также безопасный способ резервного копирования ваших точечных файлов.
  • Контроль версий позволяет вам видеть, как ваши точечные файлы развиваются с течением времени.

Но если вы запустите другой экземпляр терминала, вы заметите, что ваша установка не работает! Терминал не получает ваши .bash_profile или .bashrc из пользовательской папки, поскольку предполагается, что эти файлы находятся в домашнем каталоге.

Итак, нам нужен способ синхронизировать наши точечные файлы в каталоге dotfiles с нашим домашним каталогом. Вы можете делать это как хотите, даже если это так же просто, как копирование всех файлов из вашего dotfiles каталога в домашний каталог с помощью сценария. Но есть более элегантные подходы. Давайте посмотрим на два из них.

rsync подход

Один из способов справиться с проблемой наличия ваших точечных файлов в каталоге, отличном от домашнего, - это скопировать файлы с помощью сценария. Но есть гораздо лучший способ сделать это, чем использовать команду cp: команду rsync.

Rsync, что означает удаленная синхронизация, представляет собой средство удаленной и локальной синхронизации файлов. Он использует алгоритм, который сводит к минимуму объем копируемых данных, перемещая только те части файлов, которые были изменены. Таким образом, этот подход является более эффективным и более масштабируемым, когда дело доходит до синхронизации точечных файлов. Эта статья посвящена rsync более подробно.

Выполните эту команду, чтобы синхронизировать каталог dotfiles с вашим домашним каталогом:

$ rsync . ~

Команда работает точно так же, как команда cp. Он копирует содержимое источника (текущий каталог: .) в место назначения (домашний каталог: ~).

Однако у вас могут быть служебные сценарии в каталоге точечных файлов, которые вы, возможно, не захотите копировать в домашний каталог. В этом случае вы можете исключить эти файлы с помощью флага --exclude. Фактически, вы бы предпочли не синхронизировать каталог .git в папке dotfiles с вашим домашним каталогом. Итак, вот обновленная команда:

$ rsync --exclude ".git/" . ~

Вы можете использовать флаг --exclude несколько раз, чтобы исключить несколько файлов. Этот подход используется mathiasbynens в его точечных файлах.

Символьные ссылки

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

Это подход, который я использую в моих точечных файлах, и я делаю это из-за одного большого преимущества перед подходами, основанными на копировании файлов - автообновлением. Символические ссылки в каталоге по сути являются псевдонимами исходных файлов в вашем каталоге dotfiles, поэтому любые внесенные вами изменения автоматически отражаются в нем. Это означает, что вам не нужно запускать команду / сценарий синхронизации каждый раз, когда вы вносите изменения. Это очень полезно.

Вы можете символически связать свой .bash_profile с домашним каталогом, используя команду ln с флагом -s (и флагом -v, чтобы сделать его подробным):

$ ln -sv ~/Projects/dotfiles/.bash_profile ~

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

Создание служебных скриптов для синхронизации и начальной загрузки

На этом этапе вы выполняете команды терминала для синхронизации файлов точек с домашним каталогом. Этот подход практически невозможно масштабировать, если вам нужно иметь дело с более чем 2–3 файлами.

Следовательно, лучше написать пару служебных скриптов, которые помогут держать ваши точечные файлы под контролем. У вас должен быть хотя бы один скрипт в вашем репозитории точечных файлов, который вы используете для синхронизации. Ваш сценарий синхронизации должен по существу использовать ваш механизм синхронизации для синхронизации ваших точечных файлов с домашним каталогом. Он также должен иметь механизм, исключающий синхронизацию определенных файлов. Такие файлы, как сценарий синхронизации, сценарий начальной загрузки, каталог .git, файл README.md и т. Д., Должны быть исключены.

В настоящее время у меня есть функция sync в моем сценарии bootstrap.exclude.sh, которая обрабатывает синхронизацию и исключает любые файлы с .exclude в имени файла в дополнение к указанным выше. Это довольно безотказный механизм. Вы можете проверить это здесь".

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

Одна важная вещь, для которой вы можете использовать свой сценарий начальной загрузки, - это установка пакетов и инструментов, которые вы обычно используете.

Например, я разработчик Node.js и использую Mac, поэтому я могу использовать диспетчер пакетов homebrew для установки инструментов и утилит, которые я обычно использую. Я могу включить что-то вроде этого в свой сценарий начальной загрузки:

# Make sure we’re using the latest Homebrew
brew update
# Upgrade any already-installed formulae
brew upgrade
# NodeJS
brew install node
# Heroku
brew install heroku
# Yarn - an alternative to npm
brew install yarn
# Docker for containerization
brew install docker

Этот скрипт устанавливает Node, Heroku, yarn и Docker на мой Mac. Скажем, я в конечном итоге форматирую свой Mac или покупаю новый. Мне не нужно устанавливать все, что я использую вручную. Вместо этого я могу клонировать свои точечные файлы из удаленного репозитория и запустить сценарий начальной загрузки, который настраивает все за меня. Поскольку у вас может быть много вещей, которые вы используете, лучше всего выделить это в отдельный файл. Посмотрите мой brew.exclude.sh файл для примера.

Ваш сценарий начальной загрузки должен обрабатывать следующие вещи:

  1. Создание любых соответствующих каталогов, которые вы используете (например, каталог ~/Projects).
  2. Вызовите свой сценарий синхронизации, чтобы синхронизировать ваши точечные файлы с домашним каталогом.
  3. Установите все инструменты, утилиты, языки и т. Д., Которые вы обычно используете.

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

Разделение вашего .bash_profile

По мере добавления множества псевдонимов и функций мы начинаем понимать, что .bash_profile становится довольно большим и громоздким в управлении. Давайте исправим эту проблему.

Команду source можно использовать в сценарии для выполнения команд в файле, заданном в качестве аргумента команды. Таким образом, мы можем создавать дополнительные файлы для хранения наших функций и псевдонимов и передавать их в наш .bash_profile. Обычно эти файлы называют .functions и .aliases соответственно.

Создайте .functions и .aliases с помощью этой команды (находясь в каталоге dotfiles):

$ touch .functions .aliases

Теперь вырежьте и вставьте все функции из вашего .bash_profile в .functions и все псевдонимы в .aliases. Наконец, добавьте в свой .bash_profile следующие строки:

source .functions
source .aliases

Вот что происходит, когда вы открываете новое окно терминала:

  1. .bash_profile оценивается.
  2. Команда source .functions выполняется, и теперь вы можете использовать свои функции.
  3. Команда source .aliases выполняется, и теперь вы можете использовать свои псевдонимы.

Вы можете разделить содержимое вашего .bash_profile любым удобным вам способом и просто source соответствующие файлы. Обратите внимание, что вам потребуются файлы .functions и .aliases в вашем домашнем каталоге, поэтому убедитесь, что вы синхронизировали папку dotfiles с домашним каталогом, чтобы изменения вступили в силу.

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

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

Добавление поддержки для настройки

Размещение ваших точечных файлов в общедоступном репозитории редко бывает достаточно для того, чтобы ими можно было делиться. Если вы хотите, чтобы другие поэкспериментировали с вашими точечными файлами, вам следует сделать несколько вещей:

  1. Убедитесь, что есть документация по установке и использованию ваших точечных файлов. Обычно это находится в README.md вашего проекта. Механизм, который вы используете для исключения файлов из синхронизации с домашним каталогом, также должен исключать этот файл. Вам также следует взглянуть на файлы README популярных репозиториев точечных файлов, чтобы понять, что люди туда кладут. Вот ссылка на мою.
  2. Если возможно, поддержите механизм, позволяющий людям легко настраивать ваши точечные файлы, не углубляясь в них. Этот механизм полностью ваш выбор, хотя я поделюсь своим ниже.

Примечание. В остальной части этого раздела обсуждается мой подход к безболезненной настройке моих точечных файлов. Мне лично нравится мой подход (и именно поэтому я его использую, да), но у каждого человека есть свой способ делать что-то. Я предлагаю вам проверить другие репозитории точечных файлов для вдохновения. Буду рад услышать о ваших подходах в разделе комментариев.

Для поддержки настройки все мои основные точечные файлы заканчиваются примерно так (вы можете найти пример моего .functions файла здесь).

# This should be the last line of the file
# For local changes
# Don't make edits below this
[ -f ".functions.local" ] && source ".functions.local"

По сути, каждый файл с именем .filename (например) заканчивается чем-то вроде:

[ -f ".filename.local" ] && source ".filename.local"

Эта команда проверяет, существует ли файл с таким же именем файла, но с расширением .local, и, если это так, создает его источник.

Поскольку это последняя строка файла, файл .filename.local будет получен последним, поэтому все настройки и конфигурации, определенные в нем, сохраняются и могут отменять те, которые были помещены в другие файлы.

Это позволяет людям, экспериментирующим с моими точечными файлами, настраивать их, вообще не изменяя мой код! Аккуратно, а?

Кроме того, в моем .gitignore игнорируются все .local файлы.

Следующие шаги

На данный момент вы знаете почти все, что вам нужно знать об управлении точечными файлами, но есть несколько вещей, которые упускаются в этой и предыдущей статье:

  • Настройка подсказки (это действительно искусство, и вы должны потратить на это время)
  • Использование диспетчера файлов с точками, такого как dotty (или autodot, что я придумал)

Я бы порекомендовал изучить эти вещи, когда сможете.

Заключение

Это все, что касается этой серии статей по управлению точечными файлами. Мне бы хотелось услышать ваше мнение об этой статье и даже более того, чтобы увидеть, насколько творчески вы, ребята, подойдете к своим файлам точек. Напишите мне в комментариях, чтобы рассказать, как вам понравилась эта статья, и поделитесь любыми другими известными вам приемами управления точечными файлами. Кроме того, я буду очень рад, если вы уделите минуту, чтобы оставить отзыв о моих файлах точек или предложить улучшения с помощью проблем с GitHub.

Мне настолько понравилась идея файлов точек, что она вдохновила меня на создание базовой структуры управления файлами точек - autodot. Фреймворк находится в зачаточном состоянии, поэтому я ищу энтузиастов, которые могут дать мне отзывы о фреймворке, внести свой вклад в него, рассказав мне об ошибках и запросить функции, а также внести свой вклад в код и документацию. Выделите для этого немного времени! :)



Также свяжитесь со мной на GitHub и Twitter.

Удачи и удачного программирования! :)