Почему Twine 1.9.1 все еще загружается в устаревший PyPi?

Question

Я хочу загрузить пакеты на pypi.org, как указано в документации по переносу на PyPI.org, но Twine загружает на https://upload.pypi.org/legacy/,

Он доступен на https://pypi.python.org/pypi/mypolr, но не найден на pypi.org.

Я попытался прочитать несколько других вопросов, учебных пособий и руководств.

Мой pip.ini-файл (я на Windows 10) выглядит так:

[distutils]
index-servers =
    pypi

[pypi]

У меня нет сохраненного имени пользователя или пароля, поэтому раздел [pypi] пуст (как упоминалось в документах по миграции).

Я поместил INI-файл в свою папку пользователя и подтвердил ( согласно этому ответу), что он на самом деле использует тот, который я установил (используя переменную окружения PIP_CONFIG_FILE).

Боясь, что у меня что-то не так, я также попытался без pip.ini-файла заставить Twine использовать его значения по умолчанию.

Я использую Python 3.6.3 (от Anaconda), и версии моих инструментов:

• Twine 1.9.1 (в документации по миграции написано, что должно быть 1.8+)
• setuptools 38.2.3 (в документации по миграции написано, что должно быть 27+)

Является ли это актуальным или нет, вот еще некоторая информация:

• Ссылка на мой setup.py
• setup импортируется из setuptools и не distutils.core
• README.rst используется как long description, но на странице PyPi отображаются только первые 8 звездочек заголовка. (Сравните это с этим)
• Пакет, который я загружаю, имеет версию 0.2.1 (на момент публикации)
• setuptools_scm используется для получения версий из тегов git
• сборка сделана с python setup.py sdist bdist_wheel

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

Answer 1

Вы, кажется, делаете все правильно. Twine не загружается через устаревший PyPI ( https://pypi.python.org/). Он загружается в новый PyPI ( https://pypi.org/, он же "Warehouse") через оригинальный (и пока только) API PyPI, и этот API просто называется "устаревшим".

Кроме того, ваш пакет присутствует на складе по адресу https://pypi.org/project/mypolr/; Поиск склада, очевидно, не готов к производству.

Answer 2

Документы для Warehouse объясняют эту запутанную номенклатуру. Приведенные ниже цитаты взяты с первой страницы и со страницы, посвященной устаревшему API:

Warehouse - это веб-приложение, реализующее канонический индекс пакетов Python (репозиторий); его производственное развертывание - PyPI. Он заменяет старую базу кода, на которой работает pypi.python.org.

Устаревший API

"Устаревший API" обеспечивает паритет функций с унаследованным от pypi, отсюда и термин "унаследованный".

...

Загрузить API

Конечная точка API, обслуживаемая по адресу upload.pypi.org/legacy/, представляет собой эмуляцию Warehouse устаревшего API загрузки PyPI. Это конечная точка, которую используют такие инструменты, как twine и distutils, для загрузки дистрибутивов в PyPI.

Другими словами, как я понимаю:

• PyPI когда-то был веб-приложением, размещенным на pypi.python.org. Это старое приложение, которое больше не работает, теперь называется pypi-legacy.
• PyPI теперь является веб-приложением, размещенным на pypi.org. Это новое приложение называется Warehouse. Старый pypi.python.org теперь просто перенаправление на pypi.org.
• В дополнение к некоторым новым конечным точкам, Warehouse по- прежнему предоставляет несколько конечных точек API, которые раньше были у pypi-legacy. Поскольку эти конечные точки были скопированы из pypi-legacy, они вместе известны как "устаревший API".
• Кроме того, конечная точка загрузки в Legacy API Warehouse обслуживается по пути URL/legacy, выбор именования, который снова отражает тот факт, что это (частичная) повторная реализация конечной точки, используемой для загрузки в pypi-legacy.

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

Answer 3

Если кто-то еще приходит сюда из Google и недоумевает, почему их загрузки не работают, не забудьте проверить https://status.python.org/ , чтобы убедиться, что нет сбоев. Иногда нужно просто подождать :p