Windows embeddable package что это

Posted: 6th November 2016
Category: Python
Tags: python, windows

Those who have been following Python development on Windows recently will be aware that I’ve been actively redeveloping the installer. And if you’ve been watching closely you’ll know that there are now many more ways to install the official python.org release than in the past, not even including distributions such as WinPython or Anaconda.

In this post, I’m going to discuss each of the ways you can install the official releases of Python (since version 3.5), provide some context on when and why you would choose one over another, and discuss the positives and negatives of each approach.

History

Historically, there was one single MSI installer available that was intended to cover the needs of all Python users.

This installer would allow you to select a target directory and some features from its user interface or the command line (if you know the magic words), and would generally install the full distribution with all entry points (shortcuts, etc.).

Unfortunately, due to the nature of how MSIs work, there are some limitations that affect the user experience. The most major of these is the fact that MSIs cannot decide whether elevate as part of the install — it has to be hardcoded. As a result, the old installer always requires administrative privileges just in case you choose to install for all users. This prevents installation of Python on machines where you do not have full control over the system.

Secondly, while Python is often seen as one monolithic package, it is actually made up of a number of unrelated components. For example, the test suite is often not required for correct operation, nor is the documentation and often the development headers and libraries. While MSIs do support optional features, they tend to encounter issues when performing upgrades between versions (such as forgetting which options you had selected), and in general you always need to carry around the optional components even if you’re never going to install them.

Finally, some operations that are not simple file installations can be complicated. For example, when pip is installed or the standard library is precompiled, the MSI executes a background task rather than normally installing files. Without careful configuration of the MSI, these files will not be properly uninstalled or repaired, and issues in the extraction process can cause the entire task to fail. At worst, the uninstall step could fail, which can make it impossible to uninstall Python.

Modern Era

The issues described above have been addressed by the installers available since Python 3.5. However, there are also other uses for Python that do not lend themselves to a regular installer. For example, applications that want to include Python as a runtime dependency may not want to install a global copy of Python, build machines may require semi-public but non-conflicting installs of different versions, and platform-as-a-service web hosts may not allow normal installers.

Since Python 3.5.2, the official Python releases have been made available as executable installers, embeddable ZIP packages, nuget packages and Azure site extensions. There are also a range of third-party distributions that include the official Python binaries, along with other useful tools or libraries.

How do I know if a third-party distribution has the official binaries? Find the install directory, right-click each of the exe, dll or pyd files and select Properties, then Digital Signatures. If the signature is from the Python Software Foundation, it’s the official binary and has not been modified. If there is a different signature or no signature, it may not be the same as what is released on python.org.

The Python Software Foundation certificate

Executable installers

The executable installers are the main way that users download Python, and are the featured downloads at python.org. I think of these as the Python Developer Kit.

Python 3.5.0 installer

These installers provide the most flexible user interface, include all dependencies such as system updates and the Python launcher, generate shortcuts for the interpreter, the manuals and the IDLE editor, and correctly support upgrades without forgetting about feature selection.

Two versions of the executable installer are available for any given release — one labelled “executable installer” and the other “web-based installer”.

The web-based installer is typically a small initial download (around 1MB), which gets you the installer UI shown above. After you have selected or deselected optional components, the minimum set of packages necessary to install Python will be downloaded and installed. This makes it easy to minimize overall download size since unused or unnecessary components are never downloaded, though it does require that you be connected to the internet at install time. (There’s also a command-line option to download all the packages you may ever need, which will then be used later instead of downloading them over and over again.)

The other installer includes the default set of features in the EXE itself. As a result, the initial download is around 30MB, but in most cases you can install without requiring any further internet access. For a single installation, your download will likely be 3-5MB larger compared to using the web-based installer, but if you use it to install on multiple machines then you’ll likely come out ahead.

Both executable installers result in identical installations and can be automated with identical command-line options. As I mentioned above, I think of this as the Python Developer Kit, which is why there are optional features to download debugging symbols or a complete debug build, which are not available in any other options. The Python Developer Kit provides everything necessary for someone to develop a complete Python application.

What about having a single MSI installer? There’s a section coming up about this. Just keep reading.

Embeddable package

If the executable installer is the Python Developer Kit, then the embeddable package is the Python runtime redistributable. Rather than trying to be an easy-to-use installer, this package is a simple ZIP file containing the bare minimum of Python required to run applications. This includes the python[w].exe executables, the python35.dll (or later) and python3.dll modules, the standard library extension modules (*.pyd), and a precompiled copy of the standard library stored in another ZIP file.

The resulting package is about 7MB to download and around 12MB when extracted. Documentation, tools, and shortcuts are not included, and the embeddable package does not reliably build and install packages. However, once your application is ready, rather than instructing users to install Python themselves, you can include the contents of this package in your own installer. (For example, Microsoft’s command-line tools for Azure will likely do this, and installers created using pynsist can include this package automatically.)

Using the embeddable package allows you to distribute applications on Windows that use Python as a runtime without exposing it to your users. By default, a configuration file is also included to force the use of isolated mode and prevents environment variables and registry settings from affecting it (python36._pth on Python 3.6; pyvenv.cfg for Python 3.5). On Python 3.6 this file can also specify additional search paths. If your application is hosting Python, you can also choose not to distribute python.exe or any extension modules that are not used in your application.

There is no support for pip, setuptools or distutils in the embeddable package, since the idea is that you will develop against the Python Developer Kit and then lock your dependencies when you release your application. Depending on the installer technology you are using for your application, you will probably vendor any third-party packages by copying them directly into the directory with your Python code.

See this blog post for more information about how to take advantage of the embeddable distribution.

Nuget package

Nuget is a packaging technology typically used on Windows to manage development dependencies. There are many packages available as source code or pre-built binaries, mostly for .NET assemblies, as well as build tools and extensions.

There are four Python packages available on nuget, released under my name (steve.dower) but built as part of the official python.org releases. The packages are:

  • python — the latest 3.x 64-bit
  • pythonx86 — the latest 3.x 32-bit
  • python2 — the latest 2.x 64-bit
  • python2x86 — the latest 2.x 32-bit

These may be referenced by projects in Visual Studio or directly using nuget.exe to easily install a copy of Python into a build directory. It will typically install into a directory like packages\python.3.5.2\tools\python.exe, though this can often be customised.

rem Install Python 2.7
nuget.exe install -OutputDirectory packages python2

rem Add -Prerelease to get Python 3.6
nuget.exe install -OutputDirectory packages -Prerelease python

rem More options are available
nuget.exe install -Help

The contents of the nuget package is somewhere between the full installation and the embeddable package. The headers, libs and pip are included so that you can install dependencies or build your own modules. The standard library is not zipped, but also does not include the CPython test suite or libraries intended for user interaction. Operating system updates are not included, so you will need to ensure your build machine is up to date before using these packages.

There is no configuration in these packages to restrict search paths or environment variables, as these are very important to control in build definitions. As a result, there is a high likelihood that a regular installation of Python may conflict with these packages. In general, it’s best to avoid installing Python on build machines where you are using these packages. If you need a full installation, avoid using the nuget packages or test for conflicts thoroughly. (Note that conflicts typically only occur within the same x.y version, so you can safely install 2.7 and use the 3.5 nuget packages.)

Azure Site Extensions

Update 2019: These packages have been deprecated and removed. This section is of historical interest only.

Note: This particular package is released by Microsoft and is managed by my team there. The Python Software Foundation is not responsible for this package.

Azure App Service is a platform-as-a-service offering for web services (including web apps, mobile backends, and triggered jobs). It uses site extensions to customise and enhance your web services, including a range of Python versions to simplify configuration of Python-based servers.

Because web services are sensitive to even the smallest change in a dependency, each version is available as its own package. This allows you to be confident that when your site uses one of these it is not going to change without you explicitly updating your site. The current packages available at time of writing are:

  • python352x64
  • python352x86
  • python351x64
  • python2712x64
  • python2712x86
  • python2711x64

The contents of these packages is almost entirely unmodified from the official python.org releases. Some extra files for correct installation, configuration and behaviour of the web server are included, as well as copies of pip, setuptools, and certifi. Occasionally a package will include targeted patches to fix or work around issues with the platform, but we always aim to upstream fixes as soon as possible. Under the hood, these are simply nuget packages that can also be installed using nuget.exe on any copy of Windows.

C:\> nuget.exe list python -Source https://www.siteextensions.net/api/v2/
python2711x64 2.7.11.3
python2712x64 2.7.12.2
python2712x86 2.7.12.1
python351x64 3.5.1.6
python352x64 3.5.2.2
python352x86 3.5.2.1

Visit aka.ms/PythonOnAppService for the most up-to-date information about how to use these packages on Azure App Service.

Hypothetical Futures

While that covers the current set of available installers, there are some further use-cases that are not as well served. In this section I will briefly discuss the cases that I am currently aware of and their status. There are no promises that official installation packages for these will ever be produced (bearing in mind that Python is developed almost entirely by volunteers with limited free time), but there is also nothing preventing third-parties from producing and distributing these formats.

Are you already distributing Python in any of these formats? Let me know and I’m happy to link to you, provided I’m not concerned about the contents of your distribution.

Nuget package for source/runtime dependency

Earlier I discussed the nuget packages as build tools, but the more common use of nuget packages is for build dependencies. Normally a project (typically a Visual Studio project, but nuget can also be used independently) will specify a dependency on a source or binary package and obtain build steps or configuration from a known location within the package.

Providing a nuget package containing either the Python source code or the embeddable package may simplify projects that host the runtime. These would predominantly be C/C++ projects rather than pure Python projects, but some installer toolkits may prefer a ready-to-embed nuget package rather than a plain ZIP file.

There has not been much demand for this particular format. In general, a C/C++ project can make equally good use of the current nuget packages, and would require those for the headers and libraries anyway, while the embeddable package is not always suitable for installation completely unmodified. These reduce the value of a dependency nuget package to nearly zero, which is why we currently don’t have one.

Universal Windows Platform

The Universal Windows Platform is part of Windows 10 and specifies a common API set that is available across all Windows devices. This includes PCs, tablets, phone, IoT Core, XBox, HoloLens, and likely any new Windows hardware into the future.

Providing a UWP package of Python would allow developers to distribute Python code across all of these platforms. Indeed, the team behind IoT Core have already provided their version of this package. However, as the API set is not always compatible with the Win32 API, this task requires supporting a new platform within Python (that is, sys.platform would return a value other than 'win32'). Currently nobody has completely adapted Python for UWP, added the extensions required to access new platform APIs, or fully implemented the deployment tools needed for this to be generally useful (though the IoT Core support is a huge step towards this).

Administrative Deployment

System administrators will often deploy software to some or all machines on their network using management tools such as Group Policy or System Center. While it is possible to remotely install from the executable installers, these tools often require or have enhanced functionality when the installer is a pure MSI.

Unfortunately, the issues and limitations of MSI described at the start of this post still apply. It is not possible for an MSI to install all required dependencies, create an MSI that can run without administrator privileges, and robustly ensure that upgrade and remove operations behave correctly. However, it would be possible to produce a suitable MSI and installation instructions for the limited use case of administrative deployment. Such a package would likely have these characteristics:

  • Fails if certain operating system updates are missing
  • Always requires administrator privileges
  • Only allows installation for all users
  • Only allows configuration at the command line (via msiexec)
  • Requires a separate task to precompile the standard library and install pip
  • Requires additional cleanup task when uninstalling
  • Prevents the executable installer from installing for all users

System administrators would be responsible for following the documentation associated with such an MSI, and I have no doubt that most are entirely capable of doing this. However, as this would not be a good experience for most users it cannot be the default or recommended installer. I’m aware that there are some people who are grieved by this, but interactive installs are vastly more common and so take priority when determining what to offer from python.org.

Summary

Installing Python on Windows has always been a fairly reliable process. The ability to select precisely which version you would like without fear of damaging system components allows a lot of confidence that is not always available on other platforms. Improvements in recent releases make it easier to install, upgrade and manage Python, even for non-administrator users.

We have a number of different formats in which Python may be obtained depending on your intended use. The executable installers provide the full Python Developer Kit; the embeddable package contains the runtime dependencies; nuget packages allow easy use of Python as a build tool; and site extensions for Azure App Service make it easier to manage Python as a web server dependency.

There is also potential to add new formats in the future, either through third-party distributions or as new maintainers volunteer their time towards core development. For an open-source project that is run almost entirely on volunteer time, Python is an amazing example of a robust, trustworthy product with as much flexibility as any professionally developed product.

Discussion of this post is welcome here in the comments. If you are having issues installing Python, please file an issue on bugs.python.org.

Windows Embeddable Python with virtualenv support

The repository contains code to repackage Windows Embeddable version of Python with virtualenv.

What is Windows Embeddable Python?

Windows Embeddable Python is a minimalistic Python distribution suitable for bundling Python inside applications for Windows.

The package is stored in downloads: https://www.python.org/downloads

The name of the package is: Windows x86-64 embeddable zip file

Why is it necessary to repackage ZIP with Embeddable Python?

The official version has the following limitations:

  • the package does not contain pip
  • the package does not support virtualenv
  • resolution of module path behaves slightly different
    • more details: https://dev.to/fpim/setting-up-python-s-windows-embeddable-distribution-properly-1081

How it works

  • download and unpack Windows Embeddable Python
  • extract content of pythonYY.zip to Lib, remove pythonYY.zip
  • remove pythonYY._pth file
    • this file controls behavior of imports when starting Python
  • download get-pip.py and install pip
  • pip install virtualenv
  • download or use full version of python and copy Lib\venv\scripts\nt\*.exe to python bundle
    • during the creation of virtualenv these python.exe and pythonw.exe files are being copied to virtual environment location
    • these two files are different from python.exe and pythonw.exe in the top Python directory

How to build

PowerShell:

.\Bundle-Python.ps1 -PythonVersion 3.8.6

Result Python distribution will be available in python directory.

How to build with GitHub Actions

Check the version of Python in .github/workflow/bundle-python.yaml.
Commit the change and check Actions at GitHub.com.
Zip file with the result will be available as artifact in build details.

Целью настоящего документа является предоставление обзора особенностей поведения, характерных для Windows, о которых вам следует знать при использовании Python в Microsoft Windows.

В отличие от большинства систем и служб Unix, Windows не включает в себя поддерживаемую системой установку Python . Чтобы сделать Python доступным, команда C Python в течение многих лет компилировала установщики Windows с каждым release . Эти установщики в первую очередь предназначены для добавления установки Python для каждого пользователя, при этом основной интерпретатор и library используются одним пользователем. Установщик также может устанавливаться для всех пользователей одной машины, а для локальных дистрибутивов приложений доступен отдельный ZIP-файл.

Как указано в PEP 11 , выпуск Python поддерживает только платформу Windows, в то время как Microsoft рассматривает платформу в рамках расширенной поддержки. Это означает, что Python 3.13 поддерживает Windows 8.1 и более новые версии. Если вам требуется поддержка Windows 7, установите Python 3.8.

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

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

The Microsoft Store package — это простая установка Python , которая подходит для запуска скриптов и пакетов, а также использования IDLE или других сред разработки. Для нее требуется Windows 10 и выше, но ее можно безопасно установить, не повреждая другие программы. Она также предоставляет множество удобных команд для запуска Python и его инструментов.

The nuget.org packages — это легкие установки, предназначенные для систем непрерывной интеграции. Их можно использовать для сборки пакетов Python или запуска скриптов, но они не обновляются и не имеют инструментов пользовательского интерфейса.

The embeddable package — это минимальный пакет Python , подходящий для встраивания в более крупное приложение.

4.1. Полный установщик

4.1.1. Этапы установки

Для загрузки доступны четыре установщика Python 3.13 — по два для 32- и 64-разрядной версии интерпретатора. Веб-установщик — это небольшая начальная загрузка, которая автоматически загружает необходимые компоненты по мере необходимости. Автономный установщик включает компоненты, необходимые для установки по умолчанию, и требует только подключения к Интернету для дополнительных функций. См. Installing Without Downloading для других способов избежать загрузки во время установки.

После запуска установщика можно выбрать один из двух вариантов:

Если вы выберете «Установить сейчас»:

  • Вам не нужно быть администратором (если только не требуется обновление системы для C Runtime Library или вы не устанавливаете Python Launcher for Windows для всех пользователей)
  • Python будет установлен в ваш пользовательский каталог.
  • Python Launcher for Windows будет установлен в соответствии с опцией, указанной внизу первой страницы.
  • Будут установлены стандартная библиотека, тестовый набор, лаунчер и pip.
  • Если выбрано, каталог установки будет добавлен в ваш PATH .
  • Ярлыки будут видны только текущему пользователю.

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

Для выполнения установки для всех пользователей следует выбрать «Настроить установку». В этом случае:

  • Вам может потребоваться предоставить административные полномочия или одобрение.
  • Python будет установлен в каталог Program Files.
  • Python Launcher for Windows будет установлен в каталог Windows.
  • Дополнительные функции можно выбрать во время установки.
  • Стандартный library может быть предварительно скомпилирован в байт-код
  • Если выбрано, каталог установки будет добавлен в систему PATH
  • Ярлыки доступны для всех пользователей

4.1.2 Снятие ограничения MAX_PATH

Windows исторически ограничивала длину пути 260 символами. Это означало, что пути длиннее этого значения не разрешались и возникали ошибки.

В последних версиях Windows это ограничение может быть расширено примерно до 32 000 символов. Вашему администратору необходимо будет активировать групповую политику «Включить длинные пути Win32» или установить LongPathsEnabled на 1 в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem .

Это позволяет функции open() , модулю os и большинству других функций пути принимать и возвращать пути длиной более 260 символов.

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

Изменено в версии 3.6: В Python включена поддержка длинных путей.

4.1.3 Установка без пользовательского интерфейса

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

В установщик можно передать следующие параметры (найденные при запуске установщика с помощью /? ):

Name

Description

/passive

для отображения прогресса без необходимости взаимодействия с пользователем

/quiet

для установки/удаления без отображения пользовательского интерфейса

/simple

для предотвращения настройки пользователем

/uninstall

для удаления Python (без подтверждения)

/layout [directory]

для предварительной загрузки всех компонентов

/log [filename]

для указания местоположения файлов журнала

Все остальные параметры передаются как name=value , где значение обычно 0 для отключения функции, 1 для включения функции или путь. Полный список доступных параметров показан ниже.

Name

Description

Default

InstallAllUsers

Выполните общесистемную установку.

0

TargetDir

Каталог установки

Выбрано на основе InstallAllUsers

DefaultAllUsersTargetDir

Каталог установки по умолчанию для всех пользователей

%ProgramFiles%\Python X.Y или %ProgramFiles(x86)%\Python X.Y

DefaultJustForMeTargetDir

Каталог установки по умолчанию для установок «только для меня»

%LocalAppData%\Programs\Python\PythonXY или %LocalAppData%\Programs\Python\PythonXY-32 или %LocalAppData%\Programs\Python\PythonXY-64

DefaultCustomTargetDir

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

(empty)

AssociateFiles

Создайте ассоциации файлов, если также установлен лаунчер.

1

CompileAll

Скомпилируйте все файлы .py в .pyc .

0

PrependPath

Добавьте каталоги install и Scripts к PATH и добавьте .PY к PATHEXT

0

AppendPath

Добавьте каталоги install и Scripts к PATH и добавьте .PY к PATHEXT

0

Shortcuts

Создайте ярлыки для интерпретатора, документации и IDLE, если они установлены.

1

Include_doc

Установить руководство Python

1

Include_debug

Установить отладочные двоичные файлы

0

Include_dev

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

1

Include_exe

Установите python.exe и связанные с ним файлы. Пропуск этого может привести к неработоспособной установке.

1

Include_launcher

Установите Python Launcher for Windows .

1

InstallLauncherAllUsers

Устанавливает лаунчер для всех пользователей. Также требует установки Include_launcher на 1

1

Include_lib

Установите стандартный library и модули расширения. Пропуск этого может привести к неработоспособной установке.

1

Include_pip

Установить пакет pip и setuptools

1

Include_symbols

Установить отладочные символы ( *.pdb )

0

Include_tcltk

Установить поддержку Tcl/Tk и IDLE

1

Include_test

Установить стандартный тестовый набор library

1

Include_tools

Установить служебные скрипты

1

LauncherOnly

Устанавливает только лаунчер. Это переопределит большинство других опций.

0

SimpleInstall

Отключить большую часть установочного пользовательского интерфейса

0

SimpleInstallDescription

Пользовательское сообщение, отображаемое при использовании упрощенного пользовательского интерфейса установки.

(empty)

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

python-3.9.0.exe /quiet InstallAllUsers=1 PrependPath=1 Include_test=0

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

python-3.9.0.exe InstallAllUsers=0 Include_launcher=0 Include_test=0
    SimpleInstall=1 SimpleInstallDescription="Just for me, no test suite."

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

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

<Options>
    <Option Name="InstallAllUsers" Value="no" />
    <Option Name="Include_launcher" Value="0" />
    <Option Name="Include_test" Value="no" />
    <Option Name="SimpleInstall" Value="yes" />
    <Option Name="SimpleInstallDescription">Just for me, no test suite</Option>
</Options>

4.1.4 Установка без скачивания

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

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

python-3.9.0.exe /layout [optional target directory]

Вы также можете указать опцию /quiet , чтобы скрыть отображение прогресса.

4.1.5 Изменение установки

После установки Python вы можете добавлять или удалять функции через инструмент «Программы и компоненты», который является частью Windows. Выберите запись Python и выберите «Удалить/Изменить», чтобы открыть установщик в режиме обслуживания.

«Изменить» позволяет добавлять или удалять функции, изменяя флажки — неизмененные флажки ничего не установят и не удалят. Некоторые параметры нельзя изменить в этом режиме, например, каталог установки; чтобы изменить их, вам нужно будет полностью удалить и переустановить Python .

«Восстановить» проверит все файлы, которые должны быть установлены с использованием текущих настроек, и заменит все, которые были удалены или изменены.

«Удалить» полностью удалит Python , за исключением Python Launcher for Windows , для которого имеется отдельная запись в разделе «Программы и компоненты».

4.1.6 Установка свободно-поточных двоичных файлов

Добавлено в версии 3.13: (Экспериментально)

Note

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

Для установки готовых двоичных файлов с включенной свободной потоковой обработкой (см. PEP 703 ), необходимо выбрать «Настроить установку». На второй странице опций есть флажок «Загрузить свободные потоковые двоичные файлы».

../_images/win_install_freethreaded.png

При выборе этого параметра будут загружены и установлены дополнительные двоичные файлы в то же место, что и основная установка Python . Основной исполняемый файл называется python3.13t.exe , а другие двоичные файлы получают либо суффикс t , либо полный суффикс ABI. Исходные файлы Python и связанные сторонние зависимости используются совместно с основной установкой.

Версия с бесплатным потоком регистрируется как обычная установка Python с тегом 3.13t (с суффиксом -32 или -arm64 , как обычно для этих платформ). Это позволяет инструментам обнаружить ее, а Python Launcher for Windows — поддерживать py.exe -3.13t . Обратите внимание, что лаунчер будет интерпретировать py.exe -3 (или шебанг python3 ) как «последнюю установку 3.x», которая будет предпочитать двоичные файлы с бесплатным потоком обычным, в то время как py.exe -3.13 — нет. Если вы используете короткий стиль опции, вы можете предпочесть не устанавливать двоичные файлы с бесплатным потоком в это время.

Чтобы указать опцию установки в командной строке, используйте Include_freethreaded=1 . Инструкции по предварительной загрузке дополнительных двоичных файлов для автономной установки см. в Installing Without Downloading . Опции включения отладочных символов и двоичных файлов также применимы к сборкам с свободными потоками.

Также доступны свободно-поточные двоичные файлы on nuget.org .

4.2. Пакет Microsoft Store

Добавлено в версии 3.7.2.

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

Чтобы установить пакет, убедитесь, что у вас установлены последние обновления Windows 10, и найдите в приложении Microsoft Store « Python 3.13». Убедитесь, что выбранное вами приложение опубликовано Python Software Foundation, и установите его.

Warning

Python всегда будет доступен бесплатно в Microsoft Store. Если вас просят заплатить за него, вы не выбрали правильный пакет.

После установки Python можно запустить, найдя его в меню «Пуск». Кроме того, он будет доступен из любой командной строки или сеанса PowerShell, если ввести python . Кроме того, pip и IDLE можно использовать, набрав pip или idle . IDLE также можно найти в меню «Пуск».

Все три команды также доступны с суффиксами номеров версий, например, python3.exe и python3.x.exe , а также python.exe (где 3.x — это конкретная версия, которую вы хотите запустить, например, 3.13). Откройте «Управление псевдонимами выполнения приложений» через «Пуск», чтобы выбрать, какая версия Python связана с каждой командой. Рекомендуется убедиться, что pip и idle соответствуют выбранной версии python .

Виртуальные среды можно создавать с помощью python -m venv , а затем активировать и использовать в обычном режиме.

Если вы установили другую версию Python и добавили ее в переменную PATH , она будет доступна как python.exe , а не как в Microsoft Store. Чтобы получить доступ к новой установке, используйте python3.exe или python3.x.exe .

Лаунчер py.exe обнаружит эту установку Python , но будет отдавать предпочтение установкам от традиционного установщика.

Чтобы удалить Python , откройте «Настройки» и используйте «Приложения и компоненты» или найдите Python в меню «Пуск» и щелкните правой кнопкой мыши, чтобы выбрать «Удалить». Удаление удалит все пакеты, которые вы установили непосредственно в эту установку Python , но не удалит никакие виртуальные среды.

4.2.1 Известные проблемы

4.2.1.1 Перенаправление локальных данных, реестра и временных путей

Из-за ограничений приложений Microsoft Store скрипты Python могут не иметь полного доступа к записи в общие расположения, такие как TEMP и реестр. Вместо этого он будет записывать в копию private . Если ваши скрипты должны изменять общие расположения, вам нужно будет установить полный установщик.

Во время выполнения Python будет использовать копию private известных папок Windows и реестра. Например, если переменная окружения %APPDATA% равна c:\Users\<user>\AppData\ , то при записи в C:\Users\<user>\AppData\Local будет записано в C:\Users\<user>\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\LocalCache\Local\ .

При чтении файлов Windows вернет файл из папки private или, если таковой не существует, из настоящего каталога Windows. Например, чтение C:\Windows\System32 вернет содержимое C:\Windows\System32 плюс содержимое C:\Program Files\WindowsApps\package_name\VFS\SystemX86 .

Вы можете найти реальный путь к любому существующему файлу с помощью os.path.realpath() :

>>> import os
>>> test_file = 'C:\\Users\\example\\AppData\\Local\\test.txt'
>>> os.path.realpath(test_file)
'C:\\Users\\example\\AppData\\Local\\Packages\\PythonSoftwareFoundation.Python.3.8_qbz5n2kfra8p0\\LocalCache\\Local\\test.txt'

При записи в реестр Windows возможны следующие варианты поведения:

  • Чтение из HKLM\\Software разрешено, и результаты объединяются с файлом registry.dat в пакете.
  • Запись в HKLM\\Software не допускается, если существует соответствующий ключ/значение, т.е. изменение существующих ключей.
  • Запись в HKLM\\Software разрешена, если соответствующий ключ/значение не существует в пакете и у пользователя есть соответствующие права доступа.

Более подробную информацию о технической основе этих ограничений можно найти в документации Microsoft по упакованным приложениям с полным доверием, которая в настоящее время доступна по адресу docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes .

4.3 Пакеты nuget.org

Добавлено в версии 3.5.2.

Пакет nuget.org представляет собой среду Python уменьшенного размера, предназначенную для использования в системах непрерывной интеграции и сборки, в которых нет общесистемной установки Python . Хотя nuget является «менеджером пакетов для .NET», он также отлично работает с пакетами, содержащими инструменты времени сборки.

Посетите nuget.org для получения самой последней информации об использовании nuget. Ниже приведено краткое изложение, достаточное для разработчиков Python .

Инструмент командной строки nuget.exe можно загрузить напрямую с https://aka.ms/nugetclidl , например, с помощью curl или PowerShell. С помощью инструмента последняя версия Python для 64-битных или 32-битных машин устанавливается с помощью:

nuget.exe install python -ExcludeVersion -OutputDirectory .
nuget.exe install pythonx86 -ExcludeVersion -OutputDirectory .

Чтобы выбрать определенную версию, добавьте -Version 3.x.y . Выходной каталог можно изменить с . , и пакет будет установлен в подкаталог. По умолчанию подкаталог называется так же, как и пакет, и без параметра -ExcludeVersion это имя будет включать конкретную установленную версию. Внутри подкаталога находится каталог tools , содержащий установку Python :

# Without -ExcludeVersion
> .\python.3.5.2\tools\python.exe -V
Python 3.5.2

# With -ExcludeVersion
> .\python\tools\python.exe -V
Python 3.5.2

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

Рядом с каталогом tools находится каталог build\native . Он содержит файл свойств MSBuild python.props , который можно использовать в проекте C++ для ссылки на установку Python . Включение настроек автоматически использует заголовки и импортирует libraries в вашу сборку.

Страницы с информацией о пакете на nuget.org — www.nuget.org/packages/python для 64-разрядной версии, www.nuget.org/packages/pythonx86 для 32-разрядной версии и www.nuget.org/packages/pythonarm64 для версии ARM64.

4.3.1.Свободно-поточные пакеты

Добавлено в версии 3.13: (Экспериментально)

Note

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

Пакеты, содержащие свободно-поточные двоичные файлы, называются python-freethreaded для 64-битной версии, pythonx86-freethreaded для 32-битной версии и pythonarm64-freethreaded для версии ARM64. Эти пакеты содержат как точки входа python3.13t.exe , так и python.exe , обе из которых работают свободно-поточно.

4.4 Встраиваемый пакет

Добавлено в версии 3.5.

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

При извлечении встроенный дистрибутив (почти) полностью изолирован от системы пользователя, включая переменные среды, настройки системного реестра и установленные пакеты. Стандартный library включен в виде предварительно скомпилированных и оптимизированных файлов .pyc в ZIP, а также предоставляются python3.dll , python37.dll , python.exe и pythonw.exe . Tcl/tk (включая все зависимые компоненты, такие как Idle), pip и документация Python не включены.

Note

Встроенный дистрибутив не включает Microsoft C Runtime , и установщик приложения должен предоставить его. Среда выполнения могла быть уже установлена ​​на системе пользователя ранее или автоматически через Центр обновления Windows, и ее можно обнаружить, найдя ucrtbase.dll в системном каталоге.

Пакеты сторонних разработчиков должны устанавливаться установщиком приложения вместе со встроенным дистрибутивом. Использование pip для управления зависимостями, как для обычной установки Python , не поддерживается этим дистрибутивом, хотя с некоторой осторожностью можно включить и использовать pip для автоматических обновлений. В целом, пакеты сторонних разработчиков следует рассматривать как часть приложения («vendoring»), чтобы разработчик мог обеспечить совместимость с новыми версиями перед предоставлением обновлений пользователям.

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

4.4.1.Приложение Python

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

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

Более простой подход — предоставить пакетный файл или сгенерированный ярлык, который напрямую вызывает python.exe или pythonw.exe с требуемыми аргументами командной строки. В этом случае приложение будет отображаться как Python , а не его настоящее имя, и пользователи могут столкнуться с трудностями при различении его от других запущенных процессов Python или ассоциаций файлов.

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

4.4.2.Встраивание Python

Приложения, написанные на машинном коде, часто требуют какой-либо формы языка сценариев, и встроенный дистрибутив Python может быть использован для этой цели. В общем, большая часть приложения находится в машинном коде, а некоторая часть будет либо вызывать python.exe , либо напрямую использовать python3.dll . В любом случае извлечение встроенного дистрибутива в подкаталог установки приложения достаточно для предоставления загружаемого интерпретатора Python .

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

4.5 Альтернативные пакеты

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

ActivePython

Установщик с поддержкой нескольких платформ, документация, PyWin32

Anaconda

Популярные научные модули (такие как numpy, scipy и pandas) и менеджер пакетов conda .

Менеджер по развертыванию Enthought

«Менеджер пакетов и среды нового поколения Python ».

Ранее Enthought поставляла Canopy, но это reached end of life in 2016 .

WinPython

Специализированный дистрибутив для Windows с готовыми научными пакетами и инструментами для сборки пакетов.

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

4.6 Настройка Python

Для удобного запуска Python из командной строки вы можете рассмотреть возможность изменения некоторых переменных среды по умолчанию в Windows. Хотя установщик предоставляет возможность настроить переменные PATH и PATHEXT для вас, это надежно только для одной общесистемной установки. Если вы регулярно используете несколько версий Python , рассмотрите возможность использования Python Launcher for Windows .

4.6.1 Экскурс: Установка переменных окружения

Windows позволяет настраивать переменные среды постоянно как на уровне пользователя, так и на уровне системы, или временно в командной строке.

Чтобы временно задать переменные среды, откройте командную строку и используйте команду set:

C:\>set PATH=C:\Program Files\Python 3.9;%PATH%
C:\>set PYTHONPATH=%PYTHONPATH%;C:\My_python_lib
C:\>python

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

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

Чтобы навсегда изменить переменные среды по умолчанию, нажмите «Пуск» и найдите «Изменить переменные среды» или откройте «Свойства системы», «Дополнительные параметры системы» и нажмите кнопку «Переменные среды». В этом диалоговом окне вы можете добавлять или изменять переменные пользователя и системы. Чтобы изменить переменные системы, вам нужен неограниченный доступ к вашей машине (т. е. права администратора).

Note

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

Переменная PYTHONPATH используется всеми версиями Python , поэтому вам не следует настраивать ее постоянно, если только перечисленные пути не включают только код, совместимый со всеми установленными версиями Python .

4.6.2 Поиск исполняемого файла Python

Изменено в версии 3.5.

Помимо использования автоматически созданной записи в меню «Пуск» для интерпретатора Python , вы можете запустить Python в командной строке. Установщик имеет возможность настроить это для вас.

На первой странице установщика можно выбрать опцию «Добавить Python в PATH», чтобы установщик добавил место установки в PATH . Также добавляется местоположение папки Scripts\ . Это позволяет вам ввести python для запуска интерпретатора и pip для установщика пакетов. Таким образом, вы также можете выполнять свои скрипты с параметрами командной строки, см. документацию Command line .

Если вы не включили эту опцию во время установки, вы всегда можете перезапустить установщик, выбрать Изменить и включить ее. Кроме того, вы можете вручную изменить PATH , следуя указаниям в Excursus: Setting environment variables . Вам необходимо задать переменную окружения PATH , чтобы включить каталог установки Python , отделенный точкой с запятой от других записей. Пример переменной может выглядеть следующим образом (предполагая, что первые две записи уже существуют):

C:\WINDOWS\system32;C:\WINDOWS;C:\Program Files\Python 3.9

4.7. Режим UTF-8

Добавлено в версии 3.7.

Windows по-прежнему использует устаревшие кодировки для системной кодировки (кодовая страница ANSI). Python использует ее для кодировки текстовых файлов по умолчанию (например, locale.getencoding() ).

Это может вызвать проблемы, поскольку UTF-8 широко используется в Интернете и большинстве систем Unix, включая WSL (подсистема Windows для Linux).

Вы можете использовать Python UTF-8 Mode для изменения кодировки текста по умолчанию на UTF-8. Вы можете включить Python UTF-8 Mode через параметр командной строки -X utf8 или переменную среды PYTHONUTF8=1 . См. PYTHONUTF8 для включения режима UTF-8 и Excursus: Setting environment variables для изменения переменных среды.

При включении Python UTF-8 Mode вы по-прежнему можете использовать системную кодировку (кодовую страницу ANSI) через кодек «mbcs».

Обратите внимание, что добавление PYTHONUTF8=1 к переменным среды по умолчанию повлияет на все приложения Python 3.7+ в вашей системе. Если у вас есть приложения Python 3.7+, которые полагаются на устаревшую системную кодировку, рекомендуется временно задать переменную среды или использовать параметр командной строки -X utf8 .

Note

Даже если режим UTF-8 отключен, Python по умолчанию использует UTF-8 в Windows для:

  • Консольный ввод-вывод, включая стандартный ввод-вывод (подробнее см. в PEP 528 ).
  • filesystem encoding (подробнее см. PEP 529 ).

4.8. Python Launcher для Windows

Добавлено в версии 3.3.

Запуск Python для Windows — это утилита, которая помогает находить и запускать различные версии Python . Она позволяет скриптам (или командной строке) указывать предпочтение для определенной версии Python , а также находить и запускать эту версию.

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

Первоначально пусковая установка была указана в PEP 397 .

4.8.1 Начало работы

4.8.1.1 Из командной строки

Изменено в версии 3.6.

Системные установки Python 3.3 и более поздних версий поместят лаунчер на ваш PATH . Лаунчер совместим со всеми доступными версиями Python , поэтому неважно, какая версия установлена. Чтобы проверить, доступен ли лаунчер, выполните следующую команду в командной строке:

py

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

Если у вас установлено несколько версий Python (например, 3.7 и 3.13), вы могли заметить, что была запущена версия Python 3.13. Чтобы запустить Python 3.7, попробуйте выполнить команду:

py -3.7

Если вам нужна последняя установленная у вас версия Python 2, попробуйте выполнить команду:

py -2

Если вы видите следующую ошибку, у вас не установлен лаунчер:

'py' is not recognized as an internal or external command,
operable program or batch file.

The command:

py --list

отображает текущую установленную версию(и) Python.

Аргумент -x.y — это краткая форма аргумента -V:Company/Tag , который позволяет выбрать определенную среду выполнения Python , включая те, которые могли прийти откуда-то не с python.org. Любая среда выполнения, зарегистрированная с помощью PEP 514 , будет доступна для обнаружения. Команда --list выводит список всех доступных сред выполнения с использованием формата -V: .

При использовании аргумента -V: указание Company ограничит выбор средами выполнения от этого поставщика, а указание только Tag выберет всех поставщиков. Обратите внимание, что пропуск косой черты подразумевает наличие тега:

# Select any '3.*' tagged runtime
py -V:3

# Select any 'PythonCore' released runtime
py -V:PythonCore/

# Select PythonCore's latest Python 3 runtime
py -V:PythonCore/3

Короткая форма аргумента ( -3 ) выбирает только из основных релизов Python , а не из других дистрибутивов. Однако длинная форма ( -V:3 ) выберет из любого.

Компания сопоставляется по полной строке, без учета регистра. Тег сопоставляется либо по полной строке, либо по префиксу, при условии, что следующий символ — точка или дефис. Это позволяет -V:3.1 сопоставляться с 3.1-32 , но не с 3.10 . Теги сортируются с использованием числового порядка ( 3.10 новее 3.1 ), но сравниваются с использованием текста ( -V:3.01 не соответствует 3.1 ).

4.8.1.2 Виртуальные среды

Добавлено в версии 3.5.

Если лаунчер запущен без явной спецификации версии Python и активна виртуальная среда (созданная с помощью стандартного модуля library venv или внешнего инструмента virtualenv ), лаунчер запустит интерпретатор виртуальной среды, а не глобальный. Чтобы запустить глобальный интерпретатор, либо деактивируйте виртуальную среду, либо явно укажите глобальную версию Python .

4.8.1.3 Из скрипта

Давайте создадим тестовый скрипт Python — создадим файл с именем hello.py со следующим содержимым

#! python
import sys
sys.stdout.write("hello from Python %s\n" % (sys.version,))

Из каталога, в котором находится hello.py, выполните команду:

py hello.py

Вы должны заметить, что номер версии вашей последней установки Python 2.x напечатан. Теперь попробуйте изменить первую строку на:


Повторное выполнение команды теперь должно вывести последнюю информацию о Python 3.x. Как и в приведенных выше примерах командной строки, вы можете указать более явный квалификатор версии. Если у вас установлена ​Python 3.7, попробуйте изменить первую строку на #! python3.7 , и вы должны обнаружить, что информация о версии 3.7 напечатана.

Обратите внимание, что в отличие от интерактивного использования, голый «python» будет использовать последнюю версию Python 2.x, которую вы установили. Это сделано для обратной совместимости и совместимости с Unix, где команда python обычно относится к Python 2.

4.8.1.4 Из ассоциаций файлов

Лаунчер должен был быть связан с файлами Python (т. е. файлами .py , .pyw , .pyc ) при установке. Это означает, что при двойном щелчке по одному из этих файлов в проводнике Windows будет использоваться лаунчер, и, следовательно, вы можете использовать те же средства, описанные выше, чтобы скрипт указал версию, которую следует использовать.

Главное преимущество этого заключается в том, что один лаунчер может поддерживать несколько версий Python одновременно в зависимости от содержимого первой строки.

4.8.2.Линии Шебанга

Если первая строка файла скрипта начинается с #! , то это называется строкой «shebang». Linux и другие операционные системы типа Unix имеют встроенную поддержку таких строк, и они обычно используются в таких системах для указания того, как должен выполняться скрипт. Этот лаунчер позволяет использовать те же возможности со скриптами Python в Windows, и приведенные выше примеры демонстрируют их использование.

Чтобы строки shebang в скриптах Python могли быть переносимы между Unix и Windows, этот лаунчер поддерживает ряд «виртуальных» команд для указания того, какой интерпретатор использовать. Поддерживаемые виртуальные команды:

  • /usr/bin/env
  • /usr/bin/python
  • /usr/local/bin/python
  • python

Например, если первая строка вашего скрипта начинается с

#! /usr/bin/python

Будет найден и использован Python по умолчанию или активная виртуальная среда. Поскольку многие скрипты Python , написанные для работы в Unix, уже содержат эту строку, вы должны обнаружить, что эти скрипты могут использоваться программой запуска без изменений. Если вы пишете новый скрипт в Windows, который, как вы надеетесь, будет полезен в Unix, вы должны использовать одну из строк shebang, начинающихся с /usr .

Любая из приведенных выше виртуальных команд может быть дополнена явной версией (либо только основной версией, либо основной и дополнительной версией). Кроме того, 32-битную версию можно запросить, добавив «-32» после дополнительной версии. Например, /usr/bin/python3.7-32 запросит использование 32-битной Python 3.7. Если активна виртуальная среда, версия будет проигнорирована, и будет использоваться среда.

Добавлено в версии 3.7: Начиная с лаунчера python 3.7 можно запросить 64-битную версию с помощью суффикса «-64». Кроме того, можно указать основную версию и архитектуру без дополнительной (например, /usr/bin/python3-64 ).

Изменено в версии 3.11: Суффикс «-64» устарел и теперь подразумевает «любую архитектуру, которая не является доказуемо i386/32-битной». Чтобы запросить определенную среду, используйте новый аргумент -V:TAG с полным тегом.

Изменено в версии 3.13: Виртуальные команды, ссылающиеся на python , теперь предпочитают активную виртуальную среду, а не ищут PATH . Это обрабатывает случаи, когда shebang указывает /usr/bin/env python3 , но python3.exe отсутствует в активной среде.

Форма строки shebang /usr/bin/env имеет еще одно особое свойство. Перед поиском установленных интерпретаторов Python эта форма будет искать исполняемый файл PATH для исполняемого файла Python , соответствующего имени, указанному в качестве первого аргумента. Это соответствует поведению программы Unix env , которая выполняет поиск PATH . Если исполняемый файл, соответствующий первому аргументу после команды env , не может быть найден, но аргумент начинается с python , он будет обработан так, как описано для других виртуальных команд. Переменная окружения PYLAUNCHER_NO_SEARCH_PATH может быть установлена ​​(на любое значение), чтобы пропустить этот поиск PATH .

Строки Shebang, которые не соответствуют ни одному из этих шаблонов, ищутся в разделе [commands] лаунчера .INI file . Это может использоваться для обработки определенных команд способом, который имеет смысл для вашей системы. Имя команды должно быть одним аргументом (без пробелов в исполняемом файле shebang), а подставляемое значение — это полный путь к исполняемому файлу (дополнительные аргументы, указанные в .INI, будут заключены в кавычки как часть имени файла).

[commands]
/bin/xpython=C:\Program Files\XPython\python.exe

Любые команды, не найденные в файле .INI, рассматриваются как исполняемые пути Windows, которые являются абсолютными или относительными к каталогу, содержащему файл скрипта. Это удобно для скриптов только для Windows, например, созданных установщиком, поскольку такое поведение несовместимо с оболочками в стиле Unix. Эти пути могут быть заключены в кавычки и могут включать несколько аргументов, после которых будут добавлены путь к скрипту и любые дополнительные аргументы.

4.8.3 Аргументы в строках шебанга

Линии shebang также могут указывать дополнительные параметры, которые будут переданы интерпретатору Python . Например, если у вас есть линия shebang:

#! /usr/bin/python -v

Затем Python будет запущен с опцией -v .

4.8.4. Customization

4.8.4.1. Настройка через INI-файлы

Два файла .ini будут найдены лаунчером — py.ini в каталоге данных приложения текущего пользователя ( %LOCALAPPDATA% или $env:LocalAppData ) и py.ini в том же каталоге, что и лаунчер. Те же самые файлы .ini используются как для ‘console’ версии лаунчера (т. е. py.exe), так и для ‘windows’ версии (т. е. pyw.exe).

Настройка, указанная в «каталоге приложения», будет иметь приоритет над настройкой рядом с исполняемым файлом, поэтому пользователь, у которого может не быть прав на запись в файл .ini рядом с программой запуска, может переопределить команды в этом глобальном файле .ini.

4.8.4.2. Настройка версий Python по умолчанию

В некоторых случаях в команду можно включить спецификатор версии, чтобы указать, какая версия Python будет использоваться командой. Спецификатор версии начинается с основного номера версии и может необязательно сопровождаться точкой (‘.’) и спецификатором дополнительной версии. Кроме того, можно указать, следует ли запрашивать 32- или 64-битную реализацию, добавив «-32» или «-64».

Например, строка shebang #!python не имеет квалификатора версии, тогда как #!python3 имеет квалификатор версии, который указывает только основную версию.

Если в команде не найдено ни одного квалификатора версии, можно задать переменную окружения PY_PYTHON для указания квалификатора версии по умолчанию. Если он не задан, то значение по умолчанию равно «3». Переменная может указывать любое значение, которое может быть передано в командной строке, например «3», «3.7», «3.7-32» или «3.7-64». (Обратите внимание, что опция «-64» доступна только с лаунчером, входящим в состав Python 3.7 или более поздней версии.)

Если не найдено ни одного второстепенного квалификатора версии, можно задать переменную окружения PY_PYTHON{major} (где {major} — текущий основной квалификатор версии, как определено выше) для указания полной версии. Если такой опции не найдено, лаунчер перечислит установленные версии Python и использует последний найденный второстепенный релиз для основной версии, который, скорее всего, хотя и не гарантированно, будет последней установленной версией в этом семействе.

В 64-разрядной Windows с установленными 32-разрядной и 64-разрядной реализациями одной и той же (major.minor) версии Python предпочтительнее всегда будет 64-разрядная версия. Это будет true как для 32-разрядной, так и для 64-разрядной реализации лаунчера — 32-разрядный лаунчер предпочтет выполнить установку 64-разрядной версии Python указанной версии, если она доступна. Это сделано для того, чтобы поведение лаунчера можно было предсказать, зная только, какие версии установлены на ПК, и без учета порядка, в котором они были установлены (т. е. без знания того, была ли установлена ​​последняя версия Python — 32- или 64-разрядная и соответствующая лаунчер). Как отмечено выше, для изменения этого поведения в спецификаторе версии можно использовать необязательный суффикс «-32» или «-64».

Examples:

  • Если соответствующие параметры не заданы, команды python и python2 будут использовать последнюю установленную версию Python 2.x, а команда python3 будет использовать последнюю установленную версию Python 3.x.
  • Команда python3.7 вообще не будет проверять какие-либо параметры, поскольку версии полностью указаны.
  • Если PY_PYTHON=3 , то команды python и python3 будут использовать последнюю установленную версию Python 3.
  • Если PY_PYTHON=3.7-32 , команда python будет использовать 32-разрядную реализацию 3.7, тогда как команда python3 будет использовать последнюю установленную версию Python (PY_PYTHON вообще не рассматривался, поскольку была указана основная версия.)
  • Если PY_PYTHON=3 и PY_PYTHON3=3.7 , то команды python и python3 будут использовать именно 3.7

В дополнение к переменным среды, те же настройки можно настроить в файле .INI, используемом программой запуска. Раздел в файле INI называется [defaults] , а имя ключа будет таким же, как у переменных среды, без префикса PY_ (и обратите внимание, что имена ключей в файле INI нечувствительны к регистру). Содержимое переменной среды переопределит то, что указано в файле INI.

For example:

  • Настройка PY_PYTHON=3.7 эквивалентна INI-файлу, содержащему:
[defaults]
python=3.7
  • Настройка PY_PYTHON=3 и PY_PYTHON3=3.7 эквивалентна INI-файлу, содержащему:
[defaults]
python=3
python3=3.7

4.8.5. Diagnostics

Если переменная окружения PYLAUNCHER_DEBUG установлена ​​(на любое значение), лаунчер выведет диагностическую информацию на stderr (т. е. на консоль). Хотя эта информация одновременно и многословна, и лаконична, она должна позволить вам увидеть, какие версии Python были обнаружены, почему была выбрана конкретная версия и точную командную строку, используемую для выполнения целевого Python . Она в первую очередь предназначена для тестирования и отладки.

4.8.6. Пробный прогон

Если переменная окружения PYLAUNCHER_DRYRUN установлена ​​(на любое значение), лаунчер выведет команду, которую он бы запустил, но на самом деле не запустит Python . Это может быть полезно для инструментов, которые хотят использовать лаунчер для обнаружения и последующего непосредственного запуска Python . Обратите внимание, что команда, записанная в стандартный вывод, всегда кодируется с использованием UTF-8 и может отображаться неправильно в консоли.

4.8.7 Установка по требованию

Если переменная окружения PYLAUNCHER_ALLOW_INSTALL установлена ​​(на любое значение), а запрошенная версия Python не установлена, но доступна в Microsoft Store, то средство запуска попытается установить ее. Для завершения может потребоваться взаимодействие с пользователем, и вам может потребоваться выполнить команду еще раз.

Дополнительная переменная PYLAUNCHER_ALWAYS_INSTALL заставляет лаунчер всегда пытаться установить Python, даже если он обнаружен. Это в основном предназначено для тестирования (и должно использоваться с PYLAUNCHER_DRYRUN ).

4.8.8 Коды возврата

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

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

Name

Value

Description

RC_BAD_VENV_CFG

107

pyvenv.cfg был найден, но он поврежден.

RC_CREATE_PROCESS

101

Не удалось запустить Python.

RC_INSTALLING

111

Установка началась, но после ее завершения команду необходимо будет запустить повторно.

RC_INTERNAL_ERROR

109

Неожиданная ошибка. Пожалуйста, сообщите об ошибке.

RC_NO_COMMANDLINE

108

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

RC_NO_PYTHON

103

Не удалось найти запрошенную версию.

RC_NO_VENV_CFG

106

Требовался pyvenv.cfg , но его не удалось найти.

4.9 Поиск модулей

Эти примечания дополняют описание на The initialization of the sys.path module search path подробными примечаниями по Windows.

Если файл ._pth не найден, то в Windows sys.path заполняется следующим образом:

  • В начало добавляется пустая запись, соответствующая текущему каталогу.
  • Если существует переменная окружения PYTHONPATH , как описано в Environment variables , ее записи добавляются следующими. Обратите внимание, что в Windows пути в этой переменной должны быть разделены точкой с запятой, чтобы отличать их от двоеточия, используемого в идентификаторах дисков ( C:\ и т. д.).
  • Дополнительные «пути приложений» можно добавить в реестр как подразделы \SOFTWARE\Python\PythonCore{version}\PythonPath в ульях HKEY_CURRENT_USER и HKEY_LOCAL_MACHINE . Подразделы, имеющие строки путей, разделенные точкой с запятой, в качестве значения по умолчанию, приведут к добавлению каждого пути в sys.path . (Обратите внимание, что все известные установщики используют только HKLM, поэтому HKCU обычно пуст.)
  • Если задана переменная окружения PYTHONHOME , предполагается, что она равна « Python Home». В противном случае путь к основному исполняемому файлу Python используется для поиска «файла-ориентира» ( Lib\os.py или pythonXY.zip ) для выведения « Python Home». Если найден домашний каталог Python , соответствующие подкаталоги, добавленные в sys.path ( Lib , plat-win и т. д.), основаны на этой папке. В противном случае основной путь Python создается из пути Python , сохраненного в реестре.
  • Если Python Home не может быть найден, PYTHONPATH не указан в среде и записи реестра не найдены, используется путь по умолчанию с относительными записями (например, .\Lib;.\plat-win и т. д.).

Если файл pyvenv.cfg обнаружен рядом с основным исполняемым файлом или в каталоге на один уровень выше исполняемого файла, применяются следующие варианты:

  • Если home — абсолютный путь, а PYTHONHOME не задан, этот путь используется вместо пути к основному исполняемому файлу при определении домашнего местоположения.

Конечный результат всего этого:

  • При запуске python.exe или любого другого .exe в основном каталоге Python (либо установленной версии, либо напрямую из каталога PCbuild) выводится основной путь, а основные пути в реестре игнорируются. Другие «пути приложений» в реестре всегда считываются.
  • Когда Python размещен в другом .exe (другой каталог, встроенный через COM и т. д.), « Python Home» не будет выведен, поэтому используется основной путь из реестра. Другие «пути приложений» в реестре всегда считываются.
  • Если Python не может найти свой дом и нет никаких значений реестра (замороженный .exe, какая-то очень странная настройка установки), вы получите путь с некоторыми путями по умолчанию, но относительными.

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

  • Включите файл ._pth вместе с исполняемым файлом, содержащим каталоги для включения. Это проигнорирует пути, указанные в реестре и переменных среды, а также проигнорирует site , если только import site не указан.
  • Если вы загружаете python3.dll или python37.dll в свой собственный исполняемый файл, явно установите PyConfig.module_search_paths перед Py_InitializeFromConfig() .
  • Очистите и/или перезапишите PYTHONPATH и установите PYTHONHOME перед запуском python.exe из вашего приложения.
  • Если вы не можете воспользоваться предыдущими предложениями (например, ваш дистрибутив позволяет людям запускать python.exe напрямую), убедитесь, что файл landmark ( Lib\os.py ) существует в вашем установочном каталоге. (Обратите внимание, что он не будет обнаружен внутри ZIP-файла, но вместо этого будет обнаружен правильно названный ZIP-файл.)

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

Изменения в версии 3.6: добавлена ​​поддержка файла ._pth и удалена опция applocal из pyvenv.cfg .

Изменено в версии 3.6: добавлен pythonXX.zip в качестве потенциального ориентира, если он находится непосредственно рядом с исполняемым файлом.

Не рекомендуется с версии 3.6: Модули, указанные в реестре под Modules (не PythonPath ), могут быть импортированы importlib.machinery.WindowsRegistryFinder . Этот поисковик включен в Windows в 3.6.0 и более ранних версиях, но в будущем его может потребоваться явно добавить в sys.meta_path .

4.10 Дополнительные модули

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

Стандартные модули, специфичные для Windows, описаны в документе MS Windows Specific Services .

4.10.1. PyWin32

Модуль PyWin32 от Марка Хаммонда представляет собой набор модулей для расширенной поддержки Windows. Сюда входят утилиты для:

  • Component Object Model (COM)
  • Вызовы API Win32
  • Registry
  • Event log
  • Пользовательские интерфейсы Microsoft Foundation Classes (MFC)

PythonWin — это пример приложения MFC, поставляемого с PyWin32. Это встраиваемая IDE со встроенным отладчиком.

4.10.2. cx_Freeze

cx_Freeze оборачивает скрипты Python в исполняемые программы Windows (файлы *.exe ). После этого вы можете распространять свое приложение, не требуя от пользователей установки Python .

4.11 Компиляция Python на Windows

Если вы хотите скомпилировать CPython самостоятельно, первое, что вам следует сделать, это получить source . Вы можете загрузить исходный код последней версии или просто взять свежий checkout .

Исходное дерево содержит решение сборки и файлы проекта для Microsoft Visual Studio, который является компилятором, используемым для сборки официальных релизов Python . Эти файлы находятся в каталоге PCbuild .

Общую информацию о процессе сборки см. в PCbuild/readme.txt .

Для модулей расширения обратитесь к Building C and C++ Extensions on Windows .

4.12 Другие платформы

С текущим развитием Python некоторые платформы, которые поддерживались ранее, больше не поддерживаются (из-за отсутствия пользователей или разработчиков). Проверьте PEP 11 для получения подробной информации обо всех неподдерживаемых платформах.

  • Windows CE — это no longer supported с Python 3 (если он когда-либо был).
  • Установщик Cygwin также предлагает установить Python interpreter

Подробную информацию о платформах с предварительно скомпилированными установщиками см. в документе Python for Windows .

Embeddable distribution

If there is anything I like about Windows as a pythonist, it must be that you can use embedded distribution of python.

The embedded distribution is a ZIP file containing a minimal Python environment. It is intended for acting as part of another application, rather than being directly accessed by end-users.

In my opinion, it is a portable, ready-to-ship virtualenv. However, the embedded distribution comes with some limitation:

Third-party packages should be installed by the application installer alongside the embedded distribution. Using pip to manage dependencies as for a regular Python installation is not supported with this distribution, though with some care it may be possible to include and use pip for automatic updates. In general, third-party packages should be treated as part of the application (“vendoring”) so that the developer can ensure compatibility with newer versions before providing updates to users.

Sounds scary right? It said it doesn’t even support pip. Don’t worry, followthese simple steps, you will have a fully workable embedded environment.

Get the distribution

  1. Go to https://www.python.org/downloads/windows/
  2. Choose the version python you like and download the corresponding Windows x86-64 embeddable zip file.
  3. Unzip the file.

To make this tutorial easy to follow, I am assuming that you have downloaded Python3.7 and unzipped it toC:\python\.

Get pip

The distribution does not have pip installed in place, you need to install it yourself:1. Download get-pip.py at https://bootstrap.pypa.io/get-pip.py2. Save it to c:\python\get-pip.py3. In command-line run C:\python\python get-pip.py4. pip is now installed

Config path

The runtime of this distribution doesn’t have an empty string '' added in sys.path,so that the current directory is not added into sys.path, to solve the problem,you need to:

  1. Open C:\python\python37._pth.
  2. Uncomment the line #import site and save.
  3. Create a new .py file and save it as c:\python\sitecustomize.py:
import sys
sys.path.insert(0, '')

Enter fullscreen mode

Exit fullscreen mode

lib2to3 issue

You will encounter the following error when you try to install some packages:

error: [Errno 0] Error: 'lib2to3\\Grammar3.6.5.final.0.pickle'

Enter fullscreen mode

Exit fullscreen mode

  1. Unzip C:\python\python37.zip to a new folder
  2. Delete C:\python\python37.zip
  3. Rename the new folder to python37.zip (yes, a new folder called python37.zip)

Python’s import module is able to treat zip file as folder however, it cannot read pickle file inside a zip file, so unzip it and rename it.

Running pip

If you don’t want to mess with you PATH, you can simply do the following in your window command prompt:

  1. CD C:\python\Scripts
  2. pip install xxxxx

Running Scripts

Again if you don’t want to mess with you PATH, you can simply do in your window command prompt:

  1. C:\python\python <path to your script>

Done!

The full Python installer for Windows is an executable file that is
quite often blocked by system administrators. On the python website
(https://www.python.org/downloads/windows/) you can also find the
Python “embedable” package which is just a simple zip file and can
function as a complete Python environment in a pinch – this is how to
set things up.

Enable running powershell scripts

The embedable package is just a zip file which we will expand out so
it will not adjust the registry in any way. To avoid having to set up
the environment variables endlessly we will need to run a
(virtualenv) powershell script so this needs to be enabled:


Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

Get the embedable package

The current release is 3.9.10 so all that is needed is:

wget https://www.python.org/ftp/python/3.9.10/python-3.9.10-embed-amd64.zip -o python-3.9.10-embed-amd64.zip
Expand-Archive python-3.9.10-embed-amd64.zip

Adjust the installation

By default the embedable package severely limits the search-path using
a _pth file; here we disable that and also create a missing
directory (which is fine to be empty).

mv python-3.9.10-embed-amd64\python39._pth python-3.9.10-embed-amd64\python39.pth
mkdir python-3.9.10-embed-amd64\DLLs

Get get-pip

We will want to use pip to install everything else, which we can get
and install by:

wget https://bootstrap.pypa.io/get-pip.py -o get-pip.py
python-3.9.10-embed-amd64\python.exe get-pip.py

This should now be a python environment that can install arbitary packages!

Get virtualenv and setup a test environment

We can now get virtualenv and create a new environment and install
packages into it: numpy , jupyter etc. There is one wrinkle
after a new environment is created a file (python39.zip) needs to be
manually copied into it
:

python-3.9.10-embed-amd64\python.exe -m pip install virtualenv

python-3.9.10-embed-amd64\python.exe -m virtualenv testenv
cp python-3.9.10-embed-amd64\python39.zip testenv\Scripts\
testenv\Scripts\Activate.ps1

All together


Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

wget https://www.python.org/ftp/python/3.9.10/python-3.9.10-embed-amd64.zip -o python-3.9.10-embed-amd64.zip
Expand-Archive python-3.9.10-embed-amd64.zip
wget https://bootstrap.pypa.io/get-pip.py -o get-pip.py
mv python-3.9.10-embed-amd64\python39._pth python-3.9.10-embed-amd64\python39.pth
mkdir python-3.9.10-embed-amd64\DLLs
python-3.9.10-embed-amd64\python.exe get-pip.py

python-3.9.10-embed-amd64\python.exe -m pip install virtualenv

python-3.9.10-embed-amd64\python.exe -m virtualenv testenv
cp python-3.9.10-embed-amd64\python39.zip testenv\Scripts\

testenv\Scripts\Activate.ps1




Need further advice?

Need further advice on using Python within your organisation? Contact
us at webs@bnikolic.co.uk – with over
20 years of continous experience with Python (since version 2.1!) we
are uniquely placed to offer advice as well as complete
implementations. See https://bnikolic.co.uk/2023/05/22/python-ssc

Понравилась статья? Поделить с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
  • Yandex почта приложение для windows 10
  • Программа для диджеев для windows 7
  • Windows реестр explorer exe
  • Удаленный рабочий стол windows 10 корпоративная
  • Исчезла иконка мой компьютер на windows 10