Давайте обсудим установку Python на Windows

Всегда устанавливаю Python в Program Files для всех пользователей. Для этого я скачиваю standalone установщик на официальном сайте.


Например, вот сегодня обновил Python и выбрал такие настройки:




Однако, при установке уже предупреждает, что начиная с 3.15 standalone установщикам придет конец. Это означает, что придется устанавливать Python install manager, причем его можно скачать как на официальном сайте, так и просто установить из Windows Store.

Однако, Python install manager устанавливает Python в %LocalAppData%, что для меня неприемлемо. Я не спец. данной утилитки, но вроде в документации не нашел способа установить для всех пользователей в Program Files. Если кто-то знает, подскажите, есть ли такой способ?

И вообще, давайте обсудим, кто и как устанавливает Python.

0

Сообщение от ViachaslauK Поясняю - это извращение а не скрипт.

Ну да, ну да... как обычно: не читал, но осуждаю

Сообщение от ViachaslauK В нем нет смысла.

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

Сообщение от ViachaslauK скрипты у меня немного посложнее

Да ни боже мой, это же не для хвастовства, а исключительно как пример одной из возможностей использования py.exe

Сообщение от ViachaslauK Если я обновлю для всех пип - с большой вероятностью поломаю что-то в другом и в прод может уйти непонятно что.

Это не конкретность, а общее направление, со всеми атрибутами русского "авось" и такой-то матери, которое ничуть не добавляет ясности, в чем именно проблема.
В моем скрипте, например, есть переменная $flt, в которую записываются имена модулей (вернее даже возможно использование части имени) которые категорически запрещено обновлять. Сам скрипт прост как валенок, ты верно заметил, но всё зависит от задачи (для моих - его вполне за глаза достаточно) и его можно усложнить, если конечно будет описание того, что требуется, ТЗ так сказать.

Сообщение от ViachaslauK потому что кто-то обновил пакеты

"Это всё потому, что у кого-то слишком узкие двери"... ну или, ещё вариант: "Нет, всё потому, что кто-то слишком много ест!"
Выбирай на вкус.

0

Сообщение от YuS_2 со всеми атрибутами русского "авось" и такой-то матери,

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

Сообщение от YuS_2 Ну да, ну да... как обычно: не читал, но осуждаю

Читал, осуждаю. Потому что пипу в целом наплевать на совместимость, что сказал - то он и сделает. Именно поэтому я работаю с поэтри. Именно поэтому у меня один сервис - одно окружение, со своим пайтоном, пипом и пакетами. Зачем мне тянуть для всех, например pytorch? Или держать в модулях fastapi?
Но нет смысла распинаться - если тебе на поиграться - и так сойдет. Когда это работа - такой способ не прокатывает.

0

Python install manager оказался баганутой помойкой и разрабы отказываются исправить баги: https://github.com/python/pymanager/issues/283

Ожидание:
удобная установка и удаление отдельных версий рантаймов через команды py install и py uninstall.
я уже смирился с тем, что рантаймы устанавливаются в папку \AppData\Local\Python, многие в этой теме сказали, что даже это хорошо

Реальность:
Python install manager оставляет хвосты в системе после удаления рантаймов - команда py uninstall хоть и удаляет рантайм из папки \AppData\Local\Python, но тем не менее, оставляет ярлыки, а также записи в списке установленных программ винды. Причем, запись удаленного питона из списка установленных программ удалить не получается, выдает ошибку.
Единственное решение это выполнить команду py uninstall --purge. Данная команда удаляет все рантаймы, ярлыки, записи в реестре и все прочее.
Но почему это не может быть решением проблемы?
Допустим я установил несколько версий питона
py install 3.13
py install 3.12
py install 3.11
Теперь я хочу удалить версию 3.12, но хочу оставить остальные две версии.
py uninstall 3.12 удаляет рантайм из папки \AppData\Local\Python, но оставляет мусор в системе. Т.е. мне придется вызвать py uninstall --purge, удалить прям все рантаймы, а потом заново установить те нужные мне две версии. Короче, порнография, а не менеджер установок питона.

0

Может, кому-то будет полезно...
Я установил Питон (использовал Анаконду). А потом мне он понадобился на ноутбуке... Потом - на институтском компьютере. И вот что я сделал:
- скопировал всю директорию c:\Anaconda3 на съемный диск
- создал простенький файл env.cmd, содержащий примерно следующее:


Теперь я на любой машине делаю следующее:

- подцепляю съемный диск;
- запоминаю, на какую букву он "сел" (напр. на букву g)
- запускаю cmd.exe и ввожу команду env g:

Всё! у меня под руками Питон.

2

Сообщение от Catstail Всё! у меня под руками Питон.

Хорошо, только чем это удобнее установить одной командой pyenv и получить под рукой любе весрии Пайтона. И потом через туже анаконду манаджить?

0

Сообщение от ViachaslauK только чем это удобнее установить одной командой pyenv

Сообщение от Royal_X Давайте обсудим установку Python на Windows

Pyenv does not officially support Windows and does not work in Windows outside the Windows Subsystem for Linux. Moreover, even there, the Pythons it installs are not native Windows versions but rather Linux versions running in a virtual machine -- so you won't get Windows-specific functionality. If you're in Windows, we recommend using @kirankotari's pyenv-win fork -- which does install native Windows Python versions.

pyenv-win давно не обновлялся, так что этот вариант отпадает.

К тому же, очевидно же, что существует 1000 способов установки питона. Но хотелось бы использовать официальный, и таковым на винде является Python install manager

0

ViachaslauK, не настаиваю. Полагаю, что если на компьютере Питона нет совсем, то скачать-то его придётся. А так подцепил диск - и всё.

0

Сообщение от Royal_X pyenv-win давно не обновлялся, так что этот вариант отпадает.

Зачем обновлять то, что прекрасно работает? Это просто менеджер пакетов, все последние версии питона поддерживает.

Сообщение от Catstail Полагаю, что если на компьютере Питона нет совсем, то скачать-то его придётся.

Мне очень сложно представить такую ситуацию)))

0

Сообщение от ViachaslauK Мне очень сложно представить такую ситуацию)))

сама вин 11 использует питон, по крайней мере, я видел заглушки в системных директориях, так что питон будет у всех. Но такой питон не юзабельный, он даже не вызывается из cmd. Да и не думаю, что это хорошая идея использовать непонятно какой питон. Лучше уж ставить самому, причем ту версию, которая нужна.

0

Сообщение от ViachaslauK Мне очень сложно представить такую ситуацию)))

- тем не менее... Специально посмотрю, ставили ли Питон на инст. компьютеры. На двух домашних его не было. С Питоном я близко познакомился только в 2020-м (кажется) году.

0

заглушки в системных директориях

Не использует.
Эта заглушка - лишь установщик из магазина приложений ms.

0

Catstail, у меня есть основной питон (обычно это какая-то свежая версия, ставлю крайнюю, но потом прям не часто обновляю). Вот сейчас в качестве основного питона установлена версия 3.14.2. Называю основным, поскольку именно под него созданы виртуальные окружения для проектов VS Code (а у меня там разнообразные проекты, есть даже Jupyter ноутбуки). Т.е. после смены основного питона придется пересоздать виртуальные окружения и заново ставить нужные пакеты, поэтому не часто обновляю основной питон.

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

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

Python install manager я использую для скачивания этих специфичных версий питона. Потом я копирую скачанные питоны из \AppData\Local\Python в папку, где они должны лежать, и через Python install manager снова удаляю эти специфичные версии.
Конечно, вы можете спросить, почему я не использую embedded питоны из официального сайта https://www.python.org/downloads/windows/, там они есть под любую версию? Проблема в том, что они урезаны и иногда создают проблемы, поэтому я предпочитаю скачивать полноценные питоны, удаляю из папок ненужные вещи, типа документации, и использую их как embedded.

Добавлено через 1 минуту

Сообщение от Rius Не использует. Эта заглушка - лишь установщик из магазина приложений ms.

ну ок, я лишь ввел where python и увидел питоны в тех местах, где я их не устанавливал...

1

Сообщение от Royal_X меня есть основной питон (обычно это какая-то свежая версия, ставлю крайнюю, но потом прям не часто обновляю). Вот сейчас в качестве основного питона установлена версия 3.14.2. Называю основным, поскольку именно под него созданы виртуальные окружения для проектов VS Code (а у меня там разнообразные проекты, есть даже Jupyter ноутбуки). Т.е. после смены основного питона придется пересоздать виртуальные окружения и заново ставить нужные пакеты, поэтому не часто обновляю основной питон.

Ну и вот ты уже выстрелил себе в ногу. А я через pyenv могу использовать те версии которые мне нужны в конкретном виртуальном, причем они никак не зависят от корневого пайтона. Проект переносится со всеми зависимостями и языком. У нас очень медленно поднимаются версии, до сих пор еще 3.11 как основная. Но нормальный менеджер позволяет мне на это вообще не обращать внимания. Речь про разработку. Понятно что в проде все завернуто в кубер и докер
Я не знаток Винды, но так как удаленная рабочая машина на ней - пришлось освоить. И Pyenv 3 года назад как закрыл все проблемы при установке так и до сих пор решает. И когда год назад переехали в Ажур - все прошло очень гладко с переносом проектов и настройки.

0

Сообщение от Royal_X И вообще, давайте обсудим, кто и как устанавливает Python

Он у меня в эстонской программе Thonny сидит. По крайней мере в данный момент. Ничего там не надо устанавливать, и так всё услужливо установлено эстонцами из Тартуского университета

0

Сообщение от ViachaslauK Ну и вот ты уже выстрелил себе в ногу.

Тут все равно без вариантов. Не думаю, что pyenv чем-то поможет. VS Code сам создает папку .venv, в которой в pyvenv.cfg жестко прописывает пути. Т.е. виртуальное окружение не я создаю, а сам редактор, и он еще там много чего настраивает. Бинарные пакеты (.pyd файлы) собираются именно под эту конкретную версию. Я лишь активирую это окружение и ставлю нужные мне пакеты.
Так что, дабы виртуальное окружение было стабильным, я просто создаю новое окружение на новой версии питона, переустанавливая нужные мне пакеты.
В любое случае, нет смысла прям постоянно обновлять этот питон и гнаться за самыми свежими версиями.
Как видно на картинке, питон не такая штука, которая быстро устаревает.

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

0

Сообщение от Royal_X Тут все равно без вариантов. Не думаю, что pyenv чем-то поможет. VS Code сам создает папку .venv, в которой в pyvenv.cfg жестко прописывает пути. Т.е. виртуальное окружение не я создаю, а сам редактор, и он еще там много чего настраивает. Бинарные пакеты (.pyd файлы) собираются именно под эту конкретную версию. Я лишь активирую это окружение и ставлю нужные мне пакеты.

Тут или я тебя не понимаю или одно из двух)))
Виртуальное окружение - полностью изолированная среда под версию пайтона. Есму все равно что там в корневом питоне стоит, оно работает со своими зависимостями. Работать с корневым пайтоном - дурной тон. Также как с пипом напрямую, например. Давно используем поэтри

0

Сообщение от ViachaslauK Виртуальное окружение - полностью изолированная среда под версию пайтона. Есму все равно что там в корневом питоне стоит, оно работает со своими зависимостями.

на самом деле, немного не так. Когда ты создаешь виртуальное окружение (без всяких сторонних инструментов, обычным venv), то ты при создании этого venv используешь конкретную версию питона - назовем это питоном А. Питон А на винде может лежать в Program Files (если питон устанавливался через standalone установщик) или он может лежать в \AppData\Local\Python, если устанавливался через официальный Python install manager.
Итак, для создания venv ты используешь питон А.
Допустим ты создаешь виртуальное окружение python -m venv .venv. Конкретно, тут используется питон А. Иногда пишут не просто python, а могут еще указать версию, если установлено несколько рантаймов и все они добавленны в переменные окружения пользователя или системы.
Когда виртуальное окружение уже создано, то в папке виртуального окружения есть папка Scripts и там появляется python.exe - назовем его питоном Б, pip и все прочее. То есть, ты прав, что говоришь, что виртуальное окружение после активации будет использовать свой питон Б, pip, а также зависимости, которые лежат в папке виртуального окружения в \Lib\site-packages. Однако, когда создается виртуальное окружение, то в конфиге виртуального окружения указываются также пути к питону А. Проблема в том, что питон Б не самодостаточен. Он сильно зависит от файлов базовой установки, в том числе от питона А. Прикол в том, что для экономии места при создании виртуального питона копируются не все нужные файлы питона А, поэтому когда ты работаешь в виртуальном окружении на питоне Б и его зависимостях, то тебе по-прежнему нужен питон А и прочие зависимости, лежащие в папке питона А. То есть при создании виртуального окружения копируются не все файлы, а порой создаются симлинки.
Это означает, что удаление питона А испортит виртуальное окружение. К тому же, речь шла об обновлении питона Б виртуального окружения. Некоторые зависимости ставятся под конкретную версию питона, поэтому приходится сносить полностью все виртуальное окружение с пакетами.
Вот если использовать python embedded, то там уже будет чуть иначе. Однако, все равно, когда нужно будет обновлять питон, то все равно придется сносить все виртуальное окружение и пересоздавать его на новой версии питона.

ViachaslauK, короче, вся проблема сводится к тому, что если хочешь менять версию питона виртуального окружения, то нужно заново пересоздавать виртуальное окружение и заново ставить пакеты. Тем более, некоторые пакеты работают только на конкретной версии питона.
Например, я ставлю пакет insightface. Тут обычный pip install insightface работать не будет (конкретно в моем случае), мне нужно ставить под конкретную версию: допустим у меня Python 3.13, то я должен скачать insightface-0.7.3-cp313-cp313-win_amd64.whl и устанавливать уже через этот файл.

0

Сообщение от Royal_X короче, вся проблема сводится к тому,

Вся проблема сводится к тому, что ты не хочешь слушать и использовать нормальную архитектуру. Ты правильно описал свою проблему, НО! Именно для этого и придумали pyenv, который решает эту проблему. Так же как conda
А для меня давно уже лучшее решение - Докер. Обычно в окружении я работаю примерно 15-20 со старта, потом ухожу в докер. Все! Неважно, винда у тебя или бубунта - ты всегда получаешь независимое окружение.

0

Сообщение от ViachaslauK Так же как conda

VS Code как раз позволяет выбрать между venv и conda. Но, как понимаю, тут уже мне придется дополнительно ставить Anaconda или Miniconda, поскольку venv это встроенный питоновский модуль, а conda - нет.
Однако, я спросил у ИИ можно ли обновлять питон в уже созданном виртуальном окружении conda, он ответил, что все равно придется пересоздавать виртуальное окружение и заново ставить пакеты.

Ладно, забей. Как уже сказал, посредством pip freeze > requirements.txt и pip install -r requirements.txt можно быстро воссоздать виртуальное окружение на новой версии питона. Тем более, у меня всего несколько виртуальных окружений на крайней версии питона, остальные виртуальные окружения на специфичных старинных версиях питона, которые нельзя менять - там у меня embedded питоны, которые лежат в папках самих приложений, а не установлены глобально.

0

Сообщение от Royal_X VS Code как раз позволяет выбрать между venv и conda. Но, как понимаю, тут уже мне придется дополнительно ставить Anaconda или Miniconda, поскольку venv это встроенный питоновский модуль, а conda - нет. Однако, я спросил у ИИ можно ли обновлять питон в уже созданном виртуальном окружении conda, он ответил, что все равно придется пересоздавать виртуальное окружение и заново ставить пакеты.

Ежики плакали, кололись, но продолжали....
Твое право, мне то что. Мое решение работает, чтоб ты понимал, у меня больше 15 рабочих проектов и на разных пайтонах - от 3.9 до 3.11. Одновременно. Если бы я морочился такими вещами, то давно бы уже сдох от перегрузки) А так poetry+pypenv или Docker - и все обновления одной командой. Poetry просто не пропустит несовместимые пакеты, а из проверенного окружения уже в докере собирается нужная версия, хочешь с полным дебагом в VSCode/Pycharm или продовская без лишних пакетов.

0