Как упаковать проект

Зачем мне это делать?

Когда вы публикуете код на Github, этот код может увидеть будущий работодатель. Стоит держать свой аккаунт в постоянной готовности, чтобы не было стыдно отправить ссылку на него работодателю в любой момент. Либо код может увидеть будущий пользователь.

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

Сторонние библиотеки

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

Если используется много библиотек, стоит перечислить их все в одном месте. Соберите их в файле requirements.txt с указанием точной версии, на которой велась разработка. В таком случае все зависимости можно установить простой командой pip3 install -r requirements.txt. Подробнее об этом можно прочитать в документации Python.

Лишние данные

Не стоит хранить в репозитории лишние данные, это увеличивает его вес и объём. Разработчикам придётся скачивать их вместе с репозиторием и разбираться в большем объёме файлов. Также к “лишним” относятся папки .idea, __pycache__, .vscode, .DS_Store и многие другие. Они могут вызвать конфликт с локальными данными других разработчиков.

Чтобы такого не случалось, стоит добавлять такие файлы в .gitignore и следить за тем, что вы коммитите. Github уже предлагает готовые шаблоны .gitignore для разных языков программирования. А эта статья поможет вам, если вы захотите добавить в них что-то от себя.

Чувствительные данные

В проектах часто используются данные, которые разработчики не хотят показывать всему миру, a иногда даже собственным коллегам по репозиторию. Такие данные называют чувствительными — это логины, пароли, API токены.

Для сокрытия данных разработчики используют переменные окружения, но они сбрасываются каждый раз, когда вы закрываете терминал. Чтобы они не сбрасывались, их можно сделать постоянными, но что, если у вас два проекта, в каждом из которых вам нужна переменная TOKEN?

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

LOGIN=dvmn-tasks
TOKEN=afnroeroinorf13jr94bg3fn

Чтобы создать такой файл вам может понадобиться текстовый редактор. Для Windows это Notepad++, для macOS — CotEditor. Или любой другой, который вам нравится.

Но как пользоваться этими данными? В этом вам поможет python-dotenv. Достаточно установить его с помощью pip3 и дописать в начало файла:

from dotenv import load_dotenv
load_dotenv()

Добавьте файл .env в .gitignore, чтобы случайно не закоммитить его. Не забудьте указать библиотеку python-dotenv на новой строчке в requirements.txt.

Пользоваться ими дальше можно так же, как и любыми другими переменными окружения:

import os
print(os.environ['LOGIN'])

Данные, которые попали в историю Git, злоумышленник может украсть. Недостаточно удалить токен из кода и сделать новый коммит. Что делать, если чувствительные данные попали в историю коммитов.

аrgparse

Многие инструменты для автоматизации не сумеют подать данные для input(), а вот передать аргумент при запуске — легко. Также это избавит пользователя от необходимости вводить одни и те же аргументы раз за разом через input(), если он введёт один из них неправильно. Ему будет достаточно нажать клавишу “Вверх”, и он получит команду со всеми аргументами, которые вводил в прошлый раз. Останется лишь поправить то значение, которое он ввёл неверно.

Вам пригодятся слайды по argparse или официальная документация.

README

Если однажды в ваш Github зайдёт работодатель, или просто какой-нибудь разработчик будет искать решение своей проблемы, и натолкнётся на код без документации — они, скорее всего, пролистнут дальше. Поэтому люди оставляют README.md файлы.

Но README.md с одним описанием проекта — мало. Расскажите как быстро запустить код и, если вы хотите, чтобы другие разработчики делали пулл-реквесты, сообщите им об этом. Вам поможет статья Как писать ридми, спеллчекер (например, этот) и справка по Markdown.

У меня маленький проект для себя. Зачем ему ридми?

Нейминг

Допустим, вы написали хорошее README и кто-то впечатлился вашим проектом. Перед тем, как начать с вами работать, человек обязательно заглянет в код. README для понимания всего проекта мало, нужно проверить, что вы там делали и как пишете код. Представьте, что человеку выбирает с кем работать и перед ним 2 разработчика. Первый пишет такой код:

for book in bookshelf:
    if "Fantasy" in book.genres:
        book.read()
else:
    raise ValueError("No any fantasy books on bookshelf with fantasy books!")

а второй такой:

for i in knigi:
    if "Fantasy" in i.genre:
        i.r()
else:
    pass

У первого всё просто и понятно. Код второго не хочется читать. Будьте первым разработчиком. Полезно будет почитать Стайлгайд и про Понятные названия.

Чистые функции

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

Что читать:

• Ввод/вывод vs Обработка данных
• Больше функций
• Чистые функции

LICENSE

Многие используют Github для того, чтобы выкладывать код в открытый доступ. Но, чтобы ваш код действительно попал “в открытый доступ”, приложите к нему лицензию. Github предложит вам на выбор несколько популярных лицензий. Одна из самых популярных — это лицензия MIT. Она позволяет запускать и использовать код кому угодно, даже в коммерческих целях. И при этом вы снимаете с себя ответственность за любые последствия его использования.

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

Лицензия обычно лежит в корне проекта в файле LICENSE (без расширения, не LICENSE.md, а просто LICENSE).

История коммитов

Если вам однажды потребуется отменить старые изменения в коде, их будет совершенно невозможно найти в git-history, если вы не дали им хорошие названия. Также многие разработчики, придя в проект, сперва читают историю коммитов, а не код. По хорошей истории коммитов можно понять как код писался и какие решения принимались при его написании. Слайды о именовании коммитов.

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