Aws-cli: Windows AWSCLI64PY3 MSI, больше не поставляющий aws.exe, ломает скрипты

@DanielLaberge - Спасибо, что

aws-cli / 1.16.37 Python / 3.6.0 Windows / 10 ботокор / 1.12.27

Установлено из этого пакета: AWSCLI64PY3.msi, ссылка на который есть на этой странице

Я заметил, что имя пакета изменилось, до недавнего времени оно было «AWSCLI64.msi».

мы тоже столкнулись с той же проблемой. Есть ли причина удаления exe?

Мы запускаем aws-cli/1.16.40 Python/3.6.0 Windows/10 botocore/1.12.30 и наши сценарии сборки Cake больше не запускаются в результате этого изменения.

Развертывание инструментов cli по этой ссылке на данный момент решило нашу проблему:
https://s3.amazonaws.com/aws-cli/AWSCLI64.msi

Интересно, что --version дает:
aws-cli/1.16.40 Python/2.7.15 Windows/10 botocore/1.12.30

Это также то, что я сделал, чтобы обойти эту проблему, некоторые страницы документации AWS по-прежнему ссылаются на пакет AWSCLI64.msi, который включает aws.exe.

Спасибо, bazwilliams, я должен был упомянуть об этом обходном пути в OP, моя проблема.

@DanielLaberge , @angelaman и @bazwilliams - Спасибо за ваш отзыв. Мне любопытно, знаете ли вы об этой странице ? Он связан с загрузкой установочных файлов AWS CLI, которые включают как 32-разрядные, так и 64-разрядные установщики MSI, и автоматически установят правильную версию. Ссылки для загрузки на https://s3.amazonaws.com/aws-cli/AWSCLISetup.exe.

Я попробовал автоматическую установку, которую вы предложили, но она по-прежнему устанавливает версию инструментов cli без двоичного файла aws.exe .

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

@justnance Как ответил @bazwilliams , ваше решение, похоже, не работает. Не знаю, почему этот билет закрывается. Не могли бы вы снова открыть его?

Я думаю, нам нужно, чтобы @DanielLaberge ответил, чтобы бот снова его открыл.

Может ли кто-то другой взять на себя эту проблему, чтобы мне не приходилось отвечать через день?

Суть проблемы не требует наличия этого бота ...

после установки этого обновления наши скрипты перестают выполняться после первого вызова aws. поскольку aws теперь является файлом .cmd, он требует префикса «call» при вызове из пакетных или cmd-файлов, без него вызывающий скрипт перестает выполняться.

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

Все - мы подтвердили, что это ошибка. Такое поведение ожидается, но непреднамеренно. В настоящее время необходимо использовать CLI с Python / 2.7.15 вместо Python / 3.6.0.

Чтобы было ясно, версия CLI MSI с этой проблемой - это наши новейшие версии MSI, созданные для python 3.6 . Мы по-прежнему публикуем более старые версии MSI, которые можно использовать в качестве временного решения для решения этой проблемы.

В настоящее время необходимо использовать CLI с Python / 2.7.15 вместо Python / 3.6.0.

Этот обходной путь недействителен, поскольку версия 2.x страдает другими дефектами .

Я бы рекомендовал перетащить файлы с именами aws в папку bin со следующим содержимым:

#!/usr/bin/env bash

self=`readlink -f "$0"`
basedir=`dirname "$self"`

"$basedir/../runtime/python.exe" -m awscli "$@"

Я понял и вроде работает нормально

$vi .bashrc

добавить ниже
псевдоним aws = 'aws.cmd'

Была проделана работа по устранению этой проблемы. Установите последнюю версию интерфейса командной строки и сообщите нам, работает ли он сейчас должным образом. Спасибо за терпеливость.

Это довольно неопределенно. Также это:

Интересно. Какую версию Windows и какой установщик вы используете?

@JordonPhillips Windows 10 17763.134. Для MSI у меня есть только номер ревизии {94E88177-499F-4DF5-8D96-25FDD46EA1C6} , созданный 12.02.2019 01:00

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

Чтобы заставить exe работать, мы полагаемся на файл, которому нужен абсолютный путь к встроенному python, поскольку относительные пути интерпретируются как относительные к текущему рабочему каталогу. (У CMD есть синтаксический обходной путь, который используется в aws.cmd , но здесь он недоступен.) Итак, в конце установки мы запускаем команды оболочки для обновления этого пути.

Вот что мы делаем:

cmd.exe /c echo "[AWSCLI64PY3_RUNTIME]python.exe" > .\bin\tmp.txt
cmd.exe /c type .\bin\aws-script.py >> .\bin\tmp.txt
cmd.exe /c move /y .\bin\tmp.txt .\bin\aws-script.py

Бит [AWSCLI64PY3_RUNTIME] является шаблоном, который просто возвращает абсолютный путь к папке runtime . Я знаю, что это выглядит немного хакерским, но на самом деле это то, что делает setuptools, и более или менее то, что делает pip (хотя pip добавляет скрипт в конец exe).

Мы запускаем тесты на этих MSI как часть выпуска, поэтому я немного удивлен, что происходит сбой во время установки. Интересно, есть ли существенная разница между Windows Server и Windows, которая вызывает проблему? Другая моя догадка заключается в том, что это какая-то проблема с разрешениями, вызывающая сбой одной из этих команд.

Я получил ту же ошибку, что и выше, при установке пакета в Windows. Что-то должно было измениться только на этой неделе, потому что на прошлой неделе все работало нормально. Я обошел ошибку, не используя пакет .msi и вместо этого загрузив версию .exe. Когда я запустил версию .exe, я увидел, что она устанавливает некоторые зависимости dotnet, и я предполагаю, что те же самые зависимости могут отсутствовать в установщике MSI?

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

@JordonPhillips Я действительно видел .\bin\aws-script.py во время установки. Я немного исследовал, потому что предполагал, что мой собственный aws.sh в каталоге bin вызывает конфликт. Я удалил его, а также попробовал еще пару вещей, чтобы попытаться пройти установку, но безрезультатно.

Таким образом, файл был фактически создан в целевом каталоге. Не уверен, что могло пойти не так после этого.

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

В тот момент, когда я получаю сообщение об ошибке, содержимое .\bin\aws-script.py :

# -*- coding: utf-8 -*-
import sys
from awscli.clidriver import main
if __name__ == '__main__':
    sys.argv[0] = 'aws'
    sys.exit(main())

Я собираюсь исследовать еще немного ...

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

Я администратор

Что произойдет, если вы запустите cmd.exe /c echo "foo" > .\bin\tmp.txt в каталоге установки?

Странно. Когда я проверяю вкладку «Безопасность» для папки bin , я получаю следующее сообщение:

---------------------------
Windows Security
---------------------------
The permissions on bin are incorrectly ordered, which may cause some entries to be ineffective.
---------------------------
OK   
---------------------------

Когда я запускаю предложенную вами команду из PowerShell с повышенными привилегиями, она работает нормально. Это все еще в том состоянии, при котором я вижу сообщение об ошибке во время установки.

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

Интересно, проблема в вызове cmd /c для выполнения команды? Может, это не удерживает админа.

Я думаю, что сам процесс cmd.exe не порождается повышенным:

msiexec.exe тоже нет.

Но это попросить возвышение во время установки , чтобы внести изменения в Program Files папку. Я ожидал, что процесс cmd.exe не будет создан с такими же привилегиями.

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

Действительно ли работает удаление и повторная установка? Похоже, это также будет проблемой при новых установках. Я не хочу остаться без CLI

Я так не думаю, но вы можете использовать либо python 2 msis, либо более старые версии python 3 msis.

Python 2: https://s3.amazonaws.com/aws-cli/AWSCLI64.msi
Старый Python 3: https://s3.amazonaws.com/aws-cli/AWSCLI64PY3-1.16.101.msi

Мы все еще работаем над исправлением, но пока кажется, что если вы запустите cmd / powershell от имени администратора, а затем запустите оттуда msiexec, все заработает.

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

Проблема заключалась в том, что по умолчанию wix (набор инструментов, используемый для создания установщиков msi) будет запускать команды cmd, используя права пользователя, запустившего установщик, а не роль администратора, которая, как предполагается, выполняет остальную часть установки. Поэтому нам просто нужно было указать ему использовать те же разрешения, что и остальная часть установки.

Потрясающе. Звучит здорово :)

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

@oliversalzburg Только что вышел релиз с исправлением.

Также, чтобы дать некоторый контекст по исходной проблеме (отсутствие exe), поскольку его здесь нет:

Для msis python 2 мы используем инструмент под названием py2exe для создания исполняемых файлов. По сути, он компилирует (почти) все, вплоть до байтового кода Python, а затем связывает достаточно, чтобы заставить работать exe. Это более-менее работает, но проект уже давно не обновляется и не работает с Python 3.

Для Python 3.6+ PSF предлагает автономную zip-версию python, предназначенную для встраивания в приложения. Поэтому, когда мы приступили к работе по переключению установщиков на Python 3, мы решили использовать это вместо этого, поскольку это намного проще, поскольку нам не нужно полагаться на сторонние зависимости.

Побочным эффектом этого было то, что у нас больше не было исполняемого файла, на который можно было бы указать, потому что CLI не использует entry_points . Даже если бы мы использовали entry_points в целом, у нас все равно не было бы работающего exe, потому что exe, сгенерированный pip, имеет абсолютный путь к исполняемому файлу python, запеченному в. Мы устанавливаем все пакеты в связанный python во время сборки , так что это будет тот же путь, который указан в нашем поле сборки. Если у вас нет такой же настройки, включая имя пользователя, это не сработает.

Итак, мы поместили cmd-скрипт в папку, которая использует путь относительно файла для вызова cli с помощью связанного python. Мы предположили, что это будет нормально, поскольку обычно Windows будет искать элементы в пути, не глядя на расширение, если вы не указали его во время работы в терминале. Ясно, что это было неправильное предположение.

Чтобы исправить это, мы посмотрели, что делают setuptools и pip для entry_points . По сути, они создали exe, который будет вызывать специальный скрипт Python. В верхней части скрипта находится шебанг с абсолютным путем к используемому питону. Проблема в том, что shebang в этом файле не может воспользоваться синтаксисом сценария cmd, который позволяет указывать путь относительно файла на диске.

Поскольку мы не знаем, по какому пути будем производить установку, до времени установки, нам нужно задать этот шебанг во время установки. Поскольку мы запускаем фактическую установку pip только при сборке msi, а не при его запуске (потому что для правильной работы msi он должен знать каждый файл, который будет создан), нам пришлось добавить shebang в специальный файл по адресу время установки. Итак, мы делаем это и включаем версию setuptools оболочки exe (версия pip зависит от файла, который заархивирован и добавлен к exe, что нам было неудобно изменять).

Здесь мы столкнулись с проблемами с разрешениями. Файлы, установленные с помощью MSI, предоставляют разрешения на чтение / выполнение только не администраторам. Наши команды для добавления shebang не имели этих разрешений (см. Предыдущий комментарий), поэтому они не прошли. Мы не обнаружили этого в нашем автоматическом тестировании, потому что пользователь оказался просто администратором, поэтому установка не могла возникнуть.

Я могу подтвердить, что проблема с установщиком теперь решена. И изначальная проблема тоже исправлена ​​:)

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