На каком окружении приложение доступно пользователю

Обновлено: 06.01.2025

При установке и первом запуске приложения, как правило, запрашивают разрешение на доступ к самым разным функциям и данным: к SMS, списку контактов, календарю, другим компонентам устройства. Как понять, какие из них нужны программе для работы, а какие — излишни и вполне могут быть уловкой мошенников? Давайте разбираться.

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

Безопаснее всего приложения от крупных известных компаний, таких, например, как Google, МТС, «Яндекс» и др. — они вряд ли будут рисковать репутацией и подсовывать потребителю сомнительный продукт.

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

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

Камера

Разрешение на работу с камерой, позволяющее делать фотоснимки и записывать видео.

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

Рекомендации: Подумайте, действительно ли приложению нужен доступ к фото- и видеосъёмке. Это так, если вы пытаетесь установить клиента соцсети (например, «Инстаграм»), где выкладка фото — обычное явление. Аналогично со списком покупок, в котором можно фотографировать продукты в супермаркете. Но если это игра вроде «5 в ряд», запрос на работу с камерой выглядит подозрительно.

Чтобы обезопасить себя, загружайте приложения только из проверенного источника — в Android это официальный магазин контента Google Play. Даже если окажетесь на сайте разработчика ПО, поищите ссылку именно на магазин, а не скачивайте напрямую — уже одно это существенно снизит риски.

Контакты

Разрешение на чтение адресной книги, изменение и добавление контактов.

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

Рекомендации: Доступ к контактам оправдан, если программа предусматривает обмен информацией с контактами из вашего списка — например, как у клиентов соцсетей и мессенджеров. Неочевидная потребность в таком разрешении должна заставить вас сомневаться.

Календарь

Разрешение на просмотр событий календаря, редактирование и создание новых событий.

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

Рекомендации: Внимательно присмотритесь к функциональности приложения. Если оно связано с инструментами планирования (например, приложение для составления списка желаний к праздникам или облачный сервис для управления проектами типа Trello), доступ к календарю можно разрешить. Но странно, если о таких правах просит, например, фонарик или диктофон.

Телефон

Разрешение на сканирование журнала вызова.

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

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

Если не давать разрешений, которые вызывают у вас сомнения, приложение может работать некорректно или вообще отказаться это делать. В таких случаях нужно расставить приоритеты: вам важнее установить конкретную программу или обезопасить свои данные? Попытайтесь найти альтернативу в том же Google Play — возможно, другое, похожее приложение запросит меньше разрешений.

Системные инструменты

Разрешение на запуск программы при загрузке, изменение состояния подключения к сети и предотвращение перехода в режим ожидания.

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

Рекомендации: Изучите возможности приложения перед установкой, а также воспользуйтесь сертифицированным мобильным ПО для безопасности, которое блокирует вредоносные программы.

Память

Разрешение на изменение или удаление содержимого карты памяти.

Риски: Приложение получает право читать, записывать, перезаписывать и удалять информацию на карте, чем пользуются похитители данных.

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

Местоположение

Разрешение на доступ к данным о геолокации устройства на основе информации о базовых станциях сотовой сети, точках доступа а также GPS и ГЛОНАСС.

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

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

Микрофон

Разрешение на запись звука с микрофона.

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

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

Нательные датчики

Доступ к данным от датчиков состояния здоровья — чаще всего пульсометру.

Риски: Приложение сможет отслеживать изменения здоровья пользователя.

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

Где посмотреть разрешения для уже установленных Android-приложений

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

Вы увидите список разрешений и узнаете, для каких приложений они одобрены. Например, в пункте «Камера» перечислены все приложения, которые имеют к ней доступ.

Открывайте приложение, если хотите изменить статус его разрешений по каждому отдельному компоненту:

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

Указывайте конкретную причину и пишите простым языком — советует UX-специалист Nielsen Norman Group Мария Росала.

Перед получением доступа к устройству пользователя (камере, геолокации, микрофону) приложение должно запросить разрешение. Оно отправляет запрос в виде модального диалогового окна.

Чтобы применить голосовой ввод в «Google Переводчике», пользователю нужно открыть приложению доступ к микрофону. Запросы на доступ в iOS (слева) и Android (справа) отличаются

Как видно на примере выше, в iOS приложение просит у пользователя доступ к микрофону, а в Android запрашивает разрешение на запись звука.

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

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

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

Дизайн запросов на доступ во многих приложениях по-прежнему оставляет желать лучшего, несмотря на большое количество рекомендаций от сообщества разработчиков iOS и Android.

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

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

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

Хорошие запросы на доступ выглядят обоснованными и ненавязчивыми, и пользователь быстро принимает решение. Плохо разработанные запросы мешают работе, путают и раздражают. Кто-то даже решит удалить приложение и скачать аналогичное только из-за непонятного запроса.

Эти три фактора значительно влияют на качество оформления запроса на доступ:

Текст в запросе на доступ.
Момент появления запроса.
Возможность изменить решение позже.

Лучший запрос на доступ — тот, который сообщает пользователю причину своего появления .

В исследовании 15 мобильных приложений Джошуа Тан из Университета Северной Дакоты и его коллеги обнаружили, что пользователи на 12% чаще соглашались открыть доступ к ресурсам устройства, если знали причину запроса.

Заинтересовавшись, исследователи проверили результативность разных причин для доступа к контактам в приложении Party Planner, которое они создали. Разница оказалась внушительной.

Оказалось, что пользователи, видевшие в запросе убедительную причину, открывали доступ к контактам на 81% чаще тех, кто видел в запросе слабую причину.

Убедительно: «Разрешите Party Planner доступ к вашим контактам, чтобы приложение запомнило адреса электронной почты ваших друзей и вводило их автоматически».
Слабо: «Party Planner хотел бы получить доступ к вашей адресной книге, чтобы показать вам самые недорогие места для развлечений неподалёку от местоположения ваших контактов».

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

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

Что делать, чтобы помочь пользователям:

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

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

В приложении United Airlines для iOS поясняющая строка написана плохо: «Использование камеры и галереи для считывания проездных документов и деталей оплаты».

Из-за такой формулировки приложение выглядит нелепо и вызывает недоверие. Кроме того, в запросе не объясняется, чем полезно открытие доступа для пользователя. К примеру, «считывание проездных документов» — просто название функции приложения. Польза — пользователю не придётся вводить данные своего паспорта вручную, если он его сфотографирует.

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

Как можно сделать — «Skyscanner запрашивает доступ к вашей геолокации для поиска наиболее подходящих авиарейсов».

Слишком часто дизайнеры Android-приложений забывают объяснить, почему приложение запрашивает доступ к ресурсам и чем это полезно для пользователя (тогда как в версиях тех же приложений на iOS с объяснениями всё идеально).

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

Заголовок: «Никогда не забывайте перезвонить». Текст: «Any.do может напомнить вам перезвонить. Не дайте важному звонку ускользнуть от вас снова». Кнопки: «Не сейчас» и «Разрешить»

Any.do, планировщик задач для Android, при запуске приложения показывает модальное окно с объяснением, что полезного получит пользователь, если откроет доступ к своим контактам. В данном случае — напоминания, что надо кому-то перезвонить.

Когда пользователь выбирает опцию «Разрешить», запускается обычный запрос на доступ в Android. Если бы при запуске приложения это окно не появилось, запрос на доступ стал бы для пользователя Android неожиданностью и, возможно, насторожил. Пользователь задался бы вопросом: зачем планировщику нужен доступ к моим контактам?

Пишите в активном залоге, простым языком, понятным вашим пользователям.
Объясните, зачем приложению понадобился доступ к ресурсам и чем это полезно для пользователя. Как правило, формула написания хорошего текста для запроса на доступ выглядит так: [название приложения] хочет получить доступ к вашему [название ресурса], чтобы вы могли [польза для пользователя или задача, которую он сможет выполнить].
Когда вы объясняете, для чего нужен запрос на доступ, избегайте расплывчатых фраз вроде «. это сделает вашу работу в приложении более комфортной». Пользователи весьма скептически относятся к туманным обещаниям и начинают подозревать, что разработчики — мошенники, и таким образом маскируют свою преступную схему.
Если вы дизайнер Android-приложений, создавайте окна с дополнительной информацией о причине запроса перед появлением запросов на доступ, которых пользователь не ожидает. Так он ещё до появления диалогового окна узнает, зачем система просит доступ к его ресурсам и какую пользу это принесёт.
Протестируйте свои запросы на пользователях, чтобы выяснить, понятен ли в них текст.

От момента зависит, посчитает пользователь запрос на доступ естественным или настораживающим.

Есть два типа запросов на доступ: связанные с контекстом происходящего и инициируемые системой. Запросы на доступ, связанные с контекстом, реже оказываются для пользователя сюрпризом: пользователи нажимают на значок в приложении (например, значок камеры или микрофона) или нажимают на поле, где нужно ввести адрес (для определения геолокации), и система реагирует на эти действия запросом на доступ.

Пользователь сам поймёт назначение запроса, когда вспомнит, какое действие он выполнил перед появлением окна.

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

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

В «Google Картах» для iOS неожиданный запрос на доступ к медиатеке, инициированный системой, появляется, когда пользователь нажимает кнопку «В путь», чтобы проложить маршрут к местной гостинице. Пользователю остаётся только гадать, для чего «Google Картам» файлы его медиатеки (ответ: для отображения в приложении информации об играющей песне).

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

В приложении Waze для Android, когда пользователь нажимает на красную кнопку микрофона, появляется запрос на доступ к записи звука. Это пример полезного запроса, который пользователь ожидает увидеть в контексте совершаемых действий

Когда пользователь устанавливает и запускает Viber на своём Android-устройстве, приложение встречает его пятью запросами на доступ подряд. Это может серьёзно утомить.

Приложение запрашивает доступ к контактам, фотографиям, камере, микрофону и геолокации. Насчёт того, зачем Viber нужен доступ к контактам, пользователь ещё может догадаться, назначение других запросов интуитивно понять сложно.

Если приложение в момент запуска не даёт пользователю спокойно работать, это может запутать и сильно озадачить. Запрашивать сразу доступ ко всем ресурсам (как делает Viber на Android) — это как просить у людей денег на «благое дело», но не уточнять, на какое именно.

Когда отправлять запрос на доступ:

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

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

Дайте возможность напрямую зайти в настройки, где можно разрешить приложению доступ к своим ресурсам.

«Нет доступа к камере. Чтобы считывать коды и делать фотографии для вашего профиля, разрешите нам использовать вашу камеру через “Настройки” → “Приватность” → “Камера”». Ниже надпись «Открыть настройки», на которую можно нажать

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

Как дизайнеру помочь пользователю:

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

С момента вступления в силу GDRP некоторые разработчики начали использовать «тёмные паттерны», чтобы подтолкнуть пользователей согласиться с запросами на доступ.

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

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

WeChat нужен доступ к контактам устройства. У пользователя есть два варианта: нажать на «Ок» (под этой кнопкой есть сноска «Рекомендуется») либо нажать на «Узнать больше»

Это уведомление от WeChat использует «тёмный паттерн»: маскирует запрос на доступ под информационное диалоговое окно. Под кнопкой «Ок» есть подпись «Рекомендуется», а возможности прямо отклонить запрос вообще нет.

Если пользователи захотят отказать приложению в доступе к своим контактам, им придётся выполнить ещё больше действий, потому что надо нажать на кнопку «Узнать больше», которая ведёт к ещё более «тёмным паттернам», затрудняющим отклонение запроса.

Не используйте «тёмные паттерны».

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

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

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

Наконец, дизайнеры не должны использовать «тёмные паттерны», а вместо этого честно давать пользователю выбор и возможность изменить его.

Python знаменит своей обширной стандартной библиотекой и девизом "батарейки в комплекте" (batteries included). Даже из коробки Python позволяет удобно и быстро решить огромный пласт задач, например, например, работа с файлами, запуск простого веб-сервера, работа с электронной почтой, парсинг XML и JSON, и так далее. Во всяком случае, это намного удобнее, чем писать shell-скрипты 😅

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

Установка сторонней библиотеки

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

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

Как pip устанавливает пакеты

Давайте разберемся, что же происходит, когда юзер набирает в терминал такую команду. В общих чертах происходит следующее.

pip обращается в PyPI (Python Package Index) и находит там запрашиваемый пакет.
Пакет скачивается. Обычно это просто zip-архив, который содержит код библиотеки, разложенный внутри согласно формату. Современным и рекомендуемым форматом пакетов является wheel (PEP-427), но в дикой природе встречаются и другие форматы.
pip устанавливает пакет.
Библиотека установлена, ее можно импортировать и использовать.

Давайте подробнее разберем третий шаг. Установка пакета — звучит загадочно и сложно, но на самом деле ничего сложного здесь не происходит. pip просто распаковывает zip-архив в определенное место (это справедливо для формата wheel, для установки пакетов в других форматах могут потребоваться дополнительные действия, но давайте разберем самый распространённый и простой случай). Куда именно происходит установка? Это можно узнать, выполнив следующую команду:

В списке sys.path можно увидеть директорию site-packages — именно туда и будет установлена библиотека. Давайте в этом убедимся.

До установки пакета:

После установки пакета:

Как видим, в директорию site-packages добавилась библиотека requests вместе со всеми своими зависимостями.

Важные мысли, которые я пытаюсь донести:

установка библиотеки напрямую влияет на файловую систему;
у интерпретатора Python есть только одна директория site-packages , куда pip и устанавливает пакеты.

А это значит, что в один интерпретатор Python нельзя установить две версии одной библиотеки одновременно. При установке новой версии предыдущая "перезатирается". Просто как если бы вы распаковали другой архив с совпадающими именами файлов в то же самое место.

Боль — это жизненный опыт

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

Например, проект А:

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

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

Надеюсь, я убедил вас, что устанавливать зависимости нескольких проектов в один интерпретатор — это очень-очень плохо. Но как же тогда правильно?

Виртуальные окружения

Решение очевидно — у каждого проекта должен быть свой интерпретатор Python, со своей собственной изолированной директорией site-packages . Это и есть основная идея, стоящая за виртуальными окружениями. Виртуальное окружение — это самостоятельная копия интерпретатора со своими пакетами.

Как создавать виртуальные окружения

Начиная с Python версии 3.5 (на данный момент это самая старая из официально поддерживаемых версий языка, так что справедливо ожидать, что как минимум везде установлен Python 3.5 или новее), создать виртуальное окружение стало очень просто:

Например, допустим, что мы работаем над проектом blog_source :

Создавать виртуальное окружения рядом с кодом — это распространённая практика, так проще ничего не перепутать, но вообще виртуальное окружение может быть где угодно, и директория тоже может называться как угодно. Обратите внимание, что если вы создаете виртуальное окружение в директории под управлением системы контроля версий (git), то его не нужно коммитить. Лучше вообще добавьте его ( env/ ) в .gitignore .

В директорию env будет скопирован тот самый интерпретатор, при помощи которого виртуальное окружение и создавалось. Т.е. если

то в виртуальном окружении будет та же самая версия:

Активируем окружение

Посмотрим, что внутри директории env :

Обратите внимание, что в директории bin есть некий файл activate в нескольких вариантах для разных шеллов. Это и есть "точка входа" в виртуальное окружение. Просто создать виртуальное окружение мало, нужно его активировать. Но сначала проверим, какие python и pip (исполняемые файлы) используются в обычном режиме работы:

Это мой обычный Python, вне виртуального окружения, назовём его глобальным. Теперь активируем виртуальное окружение:

Для Windows процесс активации будет отличаться (допустим, что виртуальное окружение создано в C:\src\blog_source ):

Обратите внимание, что приветствие шелла изменилось (добавилось (env) ), чтобы показать, что мы "внутри" виртуального окружения под названием env .

Теперь проверим еще раз, какие python и pip используются:

Посмотрите на пути — мы внутри виртуального окружения! Теперь можно смело устанавливать любые пакеты, и это никак не повлияет на глобальный Python или на другие виртуальные окружения:

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

IDE тоже нужно настроить, указав путь к bin/python внутри виртуального окружения, тогда редактор сможет лучше вам помогать.

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

И мы видим, что команда python снова вызывает глобальный интерпретатор. При этом виртуальное окружение осталось в своей директории, оно просто не активно. В следующий раз, когда будет нужно поработать с виртуальным окружением, не забудьте снова его активировать.

Виртуальное окружение можно полностью удалить, когда оно перестанет быть нужным:

В идеале, у вас должна быть возможность в любой момент удалить и пересоздать виртуальное окружение заново, для этого храните список зависимостей проекта и содержите его в актуальном состоянии (например, в requirements.txt ). В процессе разработки могут случиться всякие казусы с зависимостями, и иногда проще пересоздать виртуальное окружение заново, чем пытаться починить сломанное.

Вот так можно работать с виртуальными окружениями в Python. Всегда устанавливайте зависимости проектов только в изолированные виртуальные окружения. Не смешивайте зависимости разных проектов в одном окружении.

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

Ничего не устанавливайте в глобальный интерпретатор

Иногда возникает желание установить какой-нибудь пакет прямо в глобальный интерпретатор, потому что по смыслу этот пакет вроде как должен быть вне виртуальных окружений. Например, это может быть какая-нибудь программа, типа poetry , docker-compose , youtube-dl или howdoi . Руки набирают в терминал:

Установка начинается, прогресс-бары заполняются, но в итоге всё завершается чем-то типа такого:

Можно попробовать установить, используя sudo , и это сработает, но это считается очень плохой практикой, и я настоятельно рекомендую так не делать по нескольким причинам:

В секции про установку пакетов я упомянул, что для пакетов других форматов, кроме wheel, могут потребоваться дополнительные действия. На самом деле, при установке пакета формата sdist исполняется файл setup.py , в котором потенциально могут содержаться любые действия — от честной установки пакета, до rm -rf / или установки криптомайнера в систему. Т.к. в PyPI пакет загрузить может кто угодно, никогда нельзя быть уверенным, что именно сделает пакет при установке. Выполнять такой скрипт с системными привилегиями ( sudo ) — не самый мудрый ход.

Может нарушить целостность системы.

Часто в операционных системах принято устанавливать программы через пакетный менеджер (будь то apt , dnf или pacman ). Этот же пакетный менеджер затем может без следа удалить установленную программу, потому что он ведёт учёт файлов — какой программе какие файлы принадлежит. Если начать изменять файлы программ каким-либо образом, помимо пакетного менеджера, то это может нарушить его работу. pip , конечно, установит что нужно, но после этого могут возникнуть проблемы с системным пакетным менеджером.

сказать pip , чтобы он установил пакет не в директорию site-packages , а в домашнюю директорию пользователя при помощи флага --user :

Обязательно нужно убедиться, что директория, куда установится пакет, перечислена в переменной $PATH . Путь к директории можно получить при помощи следующей команды:

К получившемуся пути нужно в конце добавить /bin для Linux и MacOS, либо \Scripts для Windows, так что в моём случае (MacOS) в $PATH нужно добавить вот такой путь: /Users/and-semakin/.local/bin .

Подробнее про этот метод установки читайте здесь.

установить программу через пакетный менеджер ОС, например:

Часто мейнтейнеры ОС создают обёртки для пакетов из PyPI, которые можно установить при помощи системного пакетного менеджера. Как правило, такие обёртки называются python-<имя пакета> или python3-<имя пакета> . Это делается как раз для того, чтобы дать пользователям возможность устанавливать Python-программы, не нарушая работу пакетного менеджера ОС. Кроме того, эти пакеты проходят проверку безопасности, так что риск получить криптомайнер значительно ниже.

всегда устанавливайте зависимости проектов в отдельные виртуальные окружения;
если нужно установить пакет "глобально", то используйте либо pip install --user . , либо прибегните к помощи пакетного менеджера операционной системы;
никогда не используйте sudo pip . — считайте, что это табу.

Да, виртуальные окружения — определенно не самая удобная часть разработки на Python, и уж точно не самая простая тема, к этому просто нужно привыкнуть. Несколько раз повторил, выработал привычку — в целом, ничего сложного. Кроме того, экосистема Python развивается очень быстро, и я надеюсь, что скоро правильная установка пакетов и управление виртуальными окружениями станут намного легче. Уже сейчас можно пользоваться такими инструментами, которые в некоторой мере прячут от пользователя виртуальные окружения:

Android – чрезвычайно функциональная операционка. Это её и плюс, и минус одновременно. Ведь то, в чём одни видят возможности, для других является сложностью, с которой нужно разобраться. Причём последних, как показывает практика, оказывается намного больше, чем первых. Всё-таки с каждым обновлением доступных функций и инструментов Android становится больше, а значит, и больше поводов что-то не понять. Как хорошо, что у вас есть мы, готовые рассказать и показать, что к чему.

Недавно Android получил функцию передачи данных по беспроводному соединению Nearby Sharing. Google выпустила её в составе сервисов Google Play, поэтому системное обновление для этого не требовалось. Вот только у кого-то нововведение появилось в исходном названии, а у кого-то в русскоязычной локализации – «Обмен с окружением». В принципе, перевод верен, но кто вообще будет заморачиваться и искать аналогии в другом языке?

Как отключить Обмен с окружением

Итак, ещё раз: Обмен с окружением – это и есть функция передачи данных Nearby Sharing. Она позволяет передавать файлы с устройства на устройство, используя технологии Wi-Fi и Bluetooth одновременно. За счёт этого удаётся развить очень высокую скорость, при которой фотографии весом 1-4 МБ передаются практически мгновенно, а тяжёлые видеофайлы весом 1 ГБ – меньше чем за минуту.

По умолчанию «Обмен с окружением» включён всегда. Однако его можно отключить. Сделать это можно в настройках, но поскольку все производители прячут этот механизм в разные сегменты настроек, искать его лучше всего поиском:

Перейдите в «Настройки» и свайпните вниз, чтобы появилась строка поиска;
Введите в строку «Обмен с окружением» (или Nearby Sharing, если первый вариант не работает);

Отключать Обмен с окружением совсем необязательно

Откройте соответствующую вкладку, тапнув по результату в поисковой выдаче;
В открывшемся окне отключите функцию «Обмен с окружением», передвинув тумблер в неактивное положение.

Стоит ли отключать Обмен с окружением

Впрочем, отключать «Обмен с окружением» в принципе нет никакой необходимости по нескольким причинам:

Вы можете включить режим невидимки, скрывшись от пользователей не из списка контактов или вообще ото всех (так у вас сохранится возможность отправлять файлы, когда вам захочется);
Вы можете использовать как мобильный интернет для передачи данных, так и Wi-Fi, либо вообще выбрать офлайн-режим, чтобы не задействовать его, если вы боитесь перерасхода трафика;
Вы можете переключаться между разными аккаунтами Google, чтобы передавать и принимать файлы через «Обмен с окружением», так что сохранить анонимность можно и здесь.

Свободное общение и обсуждение материалов

Что может быть более тривиальное и обыденное, чем зарядка смартфона? Мы подключаем свои устройства к розетке если не каждый день, то по крайней мере 2-3 раза в неделю точно. Несмотря на то что результат всем нужен один и тот же, все выполняют этот ритуал по-своему. Одни пользуются проводной зарядкой, другие - наоборот, беспроводной, но почти все хотели бы увеличить скорость зарядки до максимума, сократив время, которое их аппарат проводит у сети электропитания. Что они для этого только ни делают. Но оправданно ли?

Как вы просыпаетесь по утрам? Наверное, тяжело. А что вас будит? Ну, конечно, будильник, который вы ставите на телефоне. Во-первых, это удобно, потому что не нужно иметь дополнительный атрибут в виде аналогового будильника. Во-вторых, это комфортно, потому что на Android, в отличие от iPhone, будильники срабатывают более мягко, аккуратно выводя вас из состояния сна. Но бывает и такое, что будильник может попросту не сработать. Недавно я сам столкнулся с подобной проблемой. Рассказываю, что делать.

Читайте также: