Почему Twine 1.9.1 все еще загружается в устаревший PyPi?
Я хочу загрузить пакеты на 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
Пожалуйста, дайте мне знать, если есть какая-либо другая информация, которая может быть полезна для выяснения этого.
3 ответа
Вы, кажется, делаете все правильно. Twine не загружается через устаревший PyPI ( https://pypi.python.org/). Он загружается в новый PyPI ( https://pypi.org/, он же "Warehouse") через оригинальный (и пока только) API PyPI, и этот API просто называется "устаревшим".
Кроме того, ваш пакет присутствует на складе по адресу https://pypi.org/project/mypolr/; Поиск склада, очевидно, не готов к производству.
Документы для 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.
Все это кажется более запутанным, чем должно быть, но это то, что есть.
Если кто-то еще приходит сюда из Google и недоумевает, почему их загрузки не работают, не забудьте проверить https://status.python.org/ , чтобы убедиться, что нет сбоев. Иногда нужно просто подождать :p