Согласованный. Текущее поведение pip для зависимостей действительно отстой.

4295

3610

[Написал в # 3939, перемещая свой комментарий сюда]

Итак, вот основная проблема: если я не хочу использовать файл requirements.txt (потому что, скажем, мне нужны декларативные зависимости, все указанные в setup.cfg ), как я должен указать URL как зависимость?

Это не работает:

[options]
install_requires = 
  requests==2.18.4
  https://github.com/example/example_lib/archive/master.zip

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

Другая проблема заключается в том, что dependency_links видимому, нельзя указать в setup.cfg, только как аргументы setup.py. Если они не используются, это следует исправить.

Есть какие-нибудь новости по этому поводу? Есть ли альтернатива в разработке? dependency_links_ кажется единственным вариантом для внутреннего / частного распространения библиотек.

Вместо того, чтобы исключать его, его следует исправить, многие люди забывают или путаются, потому что они забывают поместить как имя-версию библиотеки в install_requires, так и ссылку зависимости, которая содержит tarbal вместе с яйцом. В качестве альтернативы я бы хотел увидеть, что @jleclanche предлагает простую ссылку на архив в install_requires (указание яйца может быть необязательным).

Я не думаю, что мы одиноки: https://stackoverflow.com/questions/3472430/how-can-i-make-setuptools-install-a-package-thats-not-on-pypi

Инструменты @robertour , такие как devpi, уже много лет поддерживают более четкий подход

@dstufft btw - я хотел бы утверждать, что существование devpi демонстрирует более чистое решение проблемы, делающей ссылки зависимостей ненужными

Наследование индекса IMHO + белый список / черный список более согласован и более понятен на уровне операций

@RonnyPfannschmidt , спасибо за предложение, кажется, мне не хватает чего-то важного (дискуссии по поводу этого отказа идут слишком долго), но, вообще говоря, я не могу больше согласиться с этим комментарием от reddit :

devpi может быть решением, но добавление в игру еще одного сервиса, который требует обслуживания и необходимости ждать, пока какой-то администратор установит, не заставит меня работать в ближайшее время. Также у нас все еще будет необходимость создавать пакеты, а затем помещать их в devip (или у devpi есть функция для отслеживания репозиториев git ??)

В идеале мне нужна альтернатива, которая не потребует от меня большего, чем добавление файла в мою библиотеку или несколько строк в setup.py.

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

4175 означает, что поддержка URL-адресов PEP 508 будет в пункте 10. Я думаю, это можно закрыть.

Мысли @pfmoore @dstufft?

Я думал, что https://github.com/pypa/pip/pull/4175/commit/86b07792e7ae762beeaeb471ab9db87e31bc285d означает, что синтаксис @ не может использоваться для зависимостей, поэтому это означает, что # 4175 не является решением этой проблемы. . В комментариях говорилось, что мы не должны реализовывать поддержку @ для зависимостей до тех пор, пока PyPI не сможет заблокировать загрузки, которые использовали его (потому что мы не хотим устанавливать что-то из PyPI, чтобы иметь возможность захватывать данные с произвольных URL-адресов. , предположительно).

Его не следует объявлять устаревшим, пока не появится альтернатива, например, поддержка PEP 508. А пока им пользуется слишком много людей.

Каков правильный рабочий процесс для этого?

Допустим, есть библиотека, в которую мне нужно добавить функцию. Развернул на Github. В ближайшее время функция не будет объединена, поэтому у меня есть инструмент, который я настроил на использование моей вилки Github вместо PyPi.

Теперь все мои пользователи должны добавить --process-dependency-links при установке моего инструмента с помощью pip, что является устаревшим и даже однажды удаленным флагом?

Есть ли какой-то параметр в setup.py, который мне не хватает, или действительно нет никакого способа обойти это? Похоже, что единственный жизнеспособный способ сделать это - запустить разветвленный пакет pypi. В любом случае это только добавит путанице пользователя, когда ваш запрос на перенос действительно будет объединен.

Давайте вернемся к этому.

--process-dependency-links сегодня действительно нет альтернативы. Итак, я предлагаю продолжить и отказаться от него.

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

@pradyunsg, если нет реального плана убить его навсегда, я настоятельно рекомендую дать этому зомби отдохнуть или быть удаленным

Я не думаю, что у людей, которым это действительно нужно, есть какой-либо стимул исправить ситуацию, если только Пип не скажет: «НЕТ, я не беру ваш долг»

Как сопровождающий pip, я не могу позволить pip быть вектором для эксплойтов. Pip предполагает, что PyPI является индексом по умолчанию, поэтому в нем присутствует неявное доверие к PyPI. Итак, мои первые вопросы:

1. Существуют ли в PyPI пакеты с метаданными dependency_links ?
2. Можно ли изменить PyPI так, чтобы он отказывался от загрузки проектов с dependency_links (или уже делает это)?
3. В качестве альтернативы, может ли pip просто отказаться обрабатывать ссылки зависимости (независимо от того, установлен ли параметр) для пакетов, загруженных из PyPI?

Если бы мы могли быть уверены, что пользователи pip не могут быть укушены пакетами на PyPI с вредоносным dependency_links , я бы меньше беспокоился. Пользователи, решившие использовать настраиваемый индекс, должны сами решить, доверять ли ему. (Я бы предпочел сохранить этот флаг даже в этом случае - это потенциально удаленный эксплойт, и он всегда должен быть явно включен).

Итак, со следующими изменениями:

1. Pip никогда не будет обрабатывать ссылки зависимости из PyPI (явно или просто потому, что мы знаем, что их там нет)
2. Флаг --process-dependency-links является устаревшим, но работает только для настраиваемых индексов.

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

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

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

Вы имеете в виду номер 4175? Что заблокировано из-за 86b0779? Может быть, мы могли бы изменить https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L167, чтобы выдавать ошибку только в том случае, если comes_from - это PyPI?

Затем мы могли бы изменить предупреждение об устаревании для --process-dependency-links чтобы указать, что пользователи должны переключиться на синтаксис @ и отказаться от --process-dependency-links после разумного периода устаревания (нам нужно было бы начать часы отсчитывают время с момента, когда становится доступным синтаксис @ ).

@pfmoore Да, именно так, и это похоже на возможный путь вперед.

В ПОРЯДКЕ. Если до этого никто не дойдет, я постараюсь написать пиар.

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

Я за то, чтобы полностью отказаться от поддержки dependency_links в период прекращения поддержки. А пока добавляем поддержку зависимостей URL-адресов PEP 508, о которой я действительно думаю, что pip по-прежнему должен быть громким при использовании, и что они по-прежнему должны быть включены.

Это означало бы:

• поставить возможность обрабатывать URL-адреса PEP 508 за флагом
  
  
  
  • в сторону: следует назвать флаг так, чтобы заинтересованный в безопасности пользователь мог проверять документы
  
  
• начать отказываться от установки url-deps PEP 508, когда они поступают из пакета PyPI
• ссылки-зависимости остаются устаревшими, но у нас есть дата, когда мы их удалим
  
  
  
  • честно говоря, я не хочу давать этому больше периода устаревания, чем единственный выпуск, печатающий альтернативу.
  
  

Я напечатал это вчера, но не отправил. Теперь я понимаю, что это в основном то же самое, что и последний комментарий @pfmoore .

_ура!

Должен ли URL-адрес требовать флаг согласия? PEP 508 этого не говорит, и текущая реализация этого не делает. Я вижу логику, но не верю своим суждениям по вопросам безопасности и простоты использования.

Кроме того, я хотел бы увидеть некоторую четкую документацию о том, как проекты должны переключаться с зависимостей на синтаксис @, прежде чем мы начнем нажимать переключатель. Уже достаточно сложно достучаться до людей, которых коснутся устаревания, и предупреждения о том, что они не могут решить, что делать, не помогут. В идеале предупреждение должно включать указатель на документ «как изменить», ИМО.

Я не верю своим суждениям по вопросам безопасности и простоты использования.

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

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

Звучит неплохо.

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

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

На мой взгляд, «если пакет исходит с сервера, который вы явно указали на использование», достаточно, чтобы разрешить URL-ссылки.

Видеть? Это не значит, что у меня нет мнения, просто , что я не уверен , что мои пристрастия не показывать: улыбка:

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

Справедливо. Было бы неплохо, если бы некоторые пользователи могли дать представление о своем рабочем процессе.

"если пакет исходит от сервера, который вы явно указали на использование" достаточно, чтобы разрешить URL-ссылки.

Я здесь не уверен. : /

Видеть? Дело не в том, что у меня нет мнения, просто я не уверен, что мои предубеждения не проявляются 😄

Хе-хе.

Справедливо. Было бы неплохо, если бы некоторые пользователи могли дать представление о своем рабочем процессе.

На мой взгляд, «если пакет исходит с сервера, который вы явно указали на использование», достаточно, чтобы разрешить URL-ссылки.

Простое разрешение исходников из GitHub решит для меня 99% проблемы. В исходных пакетах есть ошибки или отсутствующие функции. Я делаю вилку и исправляю их, выдаю PR, затем жду, возможно, очень долго, чтобы их объединить и затем опубликовать на PyPI. Тем временем мои пакеты полагаются на исправления в этих пакетах.

Это можно сделать по подписке, если это можно сделать одной строкой.

Использование прямых ссылок (при условии HTTPS и т. Д.) Не является проблемой безопасности, это просто вопрос доступности. Поскольку мы запрещаем их использование в PyPI, я бы сказал, что этого достаточно, и нам не нужен другой флаг.

В моей работе мы попадаем в некоторые из упомянутых случаев использования @pfmoore , а именно: внутренняя разработка до того, как пакет будет с открытым исходным кодом, с закрытым исходным кодом и т. Д. (Всегда внутренние пакеты, зависящие от других внутренних пакетов, все они находятся на сервере контроля версий. ).
Хотя я также вижу возможный вариант использования, когда кто-то ссылается на расположение файловой системы ...
Имеет ли смысл предоставить список хостов / местоположений из белого списка? Имя флага должно быть IMO, как предлагает @pradyunsg , достаточно описательным, чтобы пользователь знал о связанных рисках. Может быть, --whitelisted-host ?

@masdeseiscaracteres Я думаю, вы неправильно поняли - я предполагал, что если пакет был получен из PyPI, мы потерпим неудачу, если какая-либо из его зависимостей будет указана через ссылку @ . Но в любом случае в PyPI таких случаев быть не должно (мы ожидаем, что в какой-то момент их отклоним, просто мы еще не смогли это настроить). Любое другое использование ссылок @ будет приемлемым.

Похоже, мы собираемся продолжить PR, который выполняет то, что описано @pfmoore в https://github.com/pypa/pip/issues/4187#issuecomment -389846189.

PR приветствуются. :)

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

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

Существующий тест test_install_pep508_with_url_in_install_requires демонстрирует это.

Что касается ошибки при установке из PyPI, я не вижу лучшего варианта, чем фактическая загрузка в PyPI чего-то, что требует URL-адреса. 😞 Я загрузил пакет на PyPI для этой цели. https://pypi.org/project/pep-508-url-deps/

Другое дело - comes_from - это не URL-адрес или путь, это строка в строках 'box==0.1.0 from file:///private/tmp/box' . Тот, кто хочет исправить эту проблему, теперь должен найти лучший способ устранения ошибки, чтобы у нас была информация о происхождении пакета. :)

@pfmoore эта проблема близка и дорога моему сердцу 😄 Дает ли загрузка @pradyunsg то, что вам нужно, и планируете ли вы ее решать? В противном случае я мог бы попытаться это сделать.

@bstrdsmkr Нет, и как говорит @pradyunsg , это не так просто, как я думал, поскольку comes_from не является исходным URL-адресом. Поэтому я не знаю, когда у меня будет время (я не использую эту функцию в личных целях, поэтому она не входит в мой список приоритетов).

Как было сказано выше, PR приветствуются :-)

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

Насколько я понимаю, желаемое исправление выглядит примерно так:

if req.url and is_like(req.url, PYPI.url):
    raise

в https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L172
где is_like() возвращает True если URL-адреса находятся в том же домене. Это правильно?

Ага. Я так думаю. Это будет изменение кода.

И нам нужно будет добавить / обновить тесты и запись в НОВОСТИ.

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

Как сопровождающий pip, я не могу позволить pip быть вектором для эксплойтов. Pip предполагает, что PyPI является индексом по умолчанию, поэтому в нем присутствует неявное доверие к PyPI.

Нет, есть явное доверие. И добавление защиты от использования внешних источников в зависимостях IMHO не улучшит ситуацию: в pypi удобнее скрывать вредоносное ПО, чем в общедоступной VCS.

ИМХО, лучшим подходом было бы использовать VCS разработчика в качестве первичных источников и сохранить pypy как реестр, указывающий на них, и прокси-сервер кеширования с некоторым надежным криптографическим доказательством того, что содержимое в VCS идентично тому, которое получено из pypy. я имею в виду

0 регистрации

dev -- public key --> pypa

1 загрузка

setuptools -- git+https:/.... --> pypa
pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks the signature matches the dev

2 холостых:

pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks it

2 извлечение

flips a coin
if coin == 1:
  pip -- give me package git+https:/... --> pypi
  pip <-- signature || content -- pypi
  pip -- give me the signature --> vcs
  pip <-- signature -- vcs
else:
  pip -- give signature of package git+https:/... --> pypi
  pip <- signature -- pypi
  pip --> Tor --> give me that commit --> vcs
  pip <-- Tor <-- here -- vcs


pip checks if the signature matches the public key and signature from pypa
pip -- give me public key --> keyserver
pip <-- PK -- keyserver
pip checks signature given by VCS against the sdist given by pypy
pip caches public key and repo location

1 установленные источники совпадают с источниками в VCS из-за подписи
2 автор тоже совпадает
3 pypa может обманывать новых пользователей, но читерство может быть обнаружено старыми
4 автор может обмануть, показывая в ветке веб-интерфейса, отличной от указанной в pypy, и отправляя в pypy другую ветку. Не получится, если мы сделаем ветку обязательной частью URI.

@KOLANICH Я думаю, вы имеете в виду PyPI (индекс упаковки Python), когда говорите pypy / pypa. PyPy - это альтернативная реализация Python. PyPA (Python Packaging Authority) - это группа добровольцев, которые поддерживают крупные проекты в области упаковки Python. Пожалуйста, уточняйте аббревиатуры или воздерживайтесь от их использования.

Вы предлагаете коренным образом изменить дизайн существующей хорошо налаженной службы. Если вы хотите внести такие серьезные изменения, вы можете предоставить по крайней мере (возможный) план перехода и реализацию POC для управления / изменения архитектуры, чтобы обеспечить переход / минимизировать поломку существующих рабочих процессов. Обратите внимание, что зависимость от внешнего хостинга - это то, что было явно удалено из PyPI в прошлом в PEP 470 , однако это был совершенно другой случай, чем то, что вы предлагаете.

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

Тем не менее, это не то место для этой дискуссии. Если вы действительно хотите предложить редизайн PyPI, я предлагаю вам начать обсуждение заново на https://github.com/pypa/warehouse.

Спасибо за предложения.

См. # 5571 - PR для объяснения, почему это было перенесено в более поздний выпуск.

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

Более того, это еще больше сбивает с толку: что вы имеете в виду, когда говорите PyPI? Вы имеете в виду какой-либо сервер, реализующий интерфейс PyPI (например, Artifactory), или, в частности, pypi.org?

Теперь очевидно, что тот, кто хочет поддержать как установку пакета с помощью setuptools (он же запускает setup.py install ), так и с помощью pip install , теперь будет в рассоле. Указание ссылок зависимости - единственный способ для кого-то в этой ситуации иметь дело с несколькими взаимозависимыми пакетами.

Теперь поправьте меня, если я ошибаюсь, но пока кажется, что если вы уберете это, основываясь на любом решении, которое PyPA приняла о загрузке на свои серверы, вы, по сути, сделаете pip бесполезным для пользователей Artifactory / компании, у которых есть частные репозитории с взаимозависимыми пакетами.

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

@ wvxvw-traiana, я думаю, вы пропустили PR # 5571
До этого PR (а в текущем выпуске - 18.0) pip отказывался устанавливать любую зависимость, указанную через синтаксис PEP508.

После этого PR (уже объединенный, поэтому он должен быть в 18.1+) pip будет отказываться от таких зависимостей только в том случае, если пакет, который зависит от них, поступает с pypi.org.

Если вы устанавливаете пакет из своего частного репо, который зависит от материала pypi, очевидно, что это нормально.
Если вы установите пакет с pypi.org, который зависит от материала из вашего частного репо, это не сработает.
Если вы устанавливаете пакет из своего частного репо, который зависит от того, что находится в вашем частном репо, это нормально.

Надеюсь, что это поможет прояснить ситуацию

@bstrdsmkr Это одно и то же происхождение или это особый случай pypi? Т.е.

Если вы устанавливаете пакет из своего частного репо, который зависит от материала из другого частного репо.

Чтобы добавить дополнительный контекст о причинах этого:

1. Прямые URL-ссылки позволяют пакету запускать загрузку и запуск произвольного кода из любого места в Интернете. Это нормально, если вы берете на себя ответственность за выполнение этого пакета, поэтому мы разрешаем прямые URL-ссылки при этом понимании.
2. Люди ожидают установки из PyPI (в частности, из PyPI, а не из индексов пакетов в целом) и доверяют пакетам, которые они скачивают оттуда. Чтобы предотвратить компрометацию пакета PyPI, раскрывающего большое количество пользователей Python, мы не разрешаем пакетам, исходящим из PyPI, зависеть от прямых URL-ссылок (потому что это налагает слишком большую нагрузку на наших пользователей, чтобы настаивать на том, чтобы они все проверяли. из PyPI, который они используют для ссылок на внешний код).
3. Связи зависимостей - это механизм, специфичный для setuptools, и они обрабатываются внутренним механизмом setuptools, а не pip. Так в отличие от прямых ссылок URL, мы не имеем никакого контроля над тем, что они делают. Вот почему мы отказались от них в пользу стандартной формы прямого URL, которую мы обрабатываем сами.

кто-то, кто хочет поддержать как установку пакета через setuptools (также известный как запуск setup.py install), так и с помощью установки pip, теперь будет в рассоле.

Если это правда, это потому, что в setuptools не реализована поддержка прямых URL-ссылок, что является согласованным стандартом. Не стесняйтесь поднимать это вместе с ними.

Если вы устанавливаете пакет из своего частного репо, который зависит от материала из другого частного репо.

Это нормально работает. PyPI не участвует.

Хорошо, с одной стороны, я счастлив, что это не влияет на меня.

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

echo "not-pypi 151.101.61.63" >> /etc/hosts
pip install --index-url not-pypi

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

Он не предназначен для того, чтобы пользователям было сложно его обойти. Это средство предложить (ограниченное) решение того факта, что PyPI еще не имеет способа заблокировать людей от загрузки пакетов с прямыми зависимостями URL. См. Https://github.com/pypa/pip/pull/4175#issuecomment -266305694 для некоторого контекста.

@dpwrussell pypi.org - особый случай. Любое частное репо к любому частному репо работает нормально после изменения.

@ wvxvw-traiana, это не значит, что вы сами не можете этого сделать. Он предназначен для того, чтобы кто-то другой не сделал этого с вами, когда вы думаете, что просто устанавливаете пакет с pypi.org.

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

5726 добавляет язык, предлагающий использовать URL-адреса PEP 508, которые IMO являются последним битом, необходимым для этого.

Ну хорошо тогда. Подведу итог:

• ссылки зависимостей по-прежнему не рекомендуются и теперь планируется удалить в pip 19.0.
• стандартная замена для него - это зависимости URL-адреса PEP 508
• Если при установке из PyPI пакет имеет зависимости URL-адреса PEP 508, установка будет прервана pip.

@pfmoore подробно изложил причины этих решений здесь: https://github.com/pypa/pip/issues/4187#issuecomment -415067034

@pradyunsg Когда будут разрешены зависимости URL-адресов PEP 508 в install_requires в setup.py? Есть ли дата?

В следующем выпуске pip - это 18.1, запланированный на октябрь. Вы можете узнать больше о трехмесячном цикле выпуска pip на https://pip.pypa.io/en/latest/development/release-process/. :)

https://github.com/pypa/wheel/issues/249 необходимо решить, прежде чем зависимости URL-адреса PEP 508 станут жизнеспособной альтернативой.

Необходимо решить проблему pypa / wheel # 249, прежде чем зависимости URL-адреса PEP 508 станут жизнеспособной альтернативой.

Это было решено.

В примечаниях к выпуску pip 18.1 говорится:

Разрешить использование требований URL-адреса PEP 508 в качестве зависимостей.

В качестве меры безопасности pip вызовет исключение при установке пакетов из PyPI, если эти пакеты зависят от пакетов, которые также не размещены на PyPI. В будущем PyPI будет напрямую блокировать загрузку пакетов с такими внешними зависимостями URL. (# 4187)

Таким образом, это в основном означает, что зависимости могут быть указаны с помощью URL-адресов, но если это не URL-адреса PyPI, пакет не может быть установлен с помощью pip? Возможно, я совершенно ошибаюсь, но как тогда должны использоваться зависимости URL-адресов?

Пакеты @JarnoRFB , размещенные в PyPI, не могут иметь зависимости URL-

Пакеты, которые НЕ размещаются в PyPI, могут иметь зависимости URL. Если вы установите пакет непосредственно из github (например), зависимости URL-адреса будут разрешены и установлены. Пример такой установки:

pip install git+https://github.com/bstrdsmkr/some_package.git

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

Незначительное дополнение:

... если вы устанавливаете с URL-адреса, это может зависеть от URL-адресов

... если вы устанавливаете с URL-адреса (VCS или иначе), локального файла или индекса пакета, который не является PyPI, он может ...

Так есть ли версия pip, которая обрабатывает install_requires в соответствии с приведенными выше описаниями? Я не могу определить теги над конечным состоянием, а текущая документация по pip указывает на документацию install_requires в setuptools, в которой все еще говорится об использовании dependency_links .

Сам не могу говорить с документами, но это «расслабление», позволяющее пакетам, не относящимся к PyPI, устанавливать зависимости от URL-адресов, было выпущено в pip 18.0

AFAIK, зависимости URL-адресов в install_requires поддерживаются начиная с pip 18.1:

Разрешить использование требований URL-адреса PEP 508 в качестве зависимостей.

Источник: примечания к выпуску

Ух, опечатка с моей стороны - @pietrodn , очевидно, верна

Я хочу оставить здесь небольшой, но успешный пример для тех, кто впервые столкнулся с этой проблемой, напуганный (как и я) тем, что делать без --process-dependency-links. Используя этот рабочий процесс, мои пользователи теперь могут выполнять установку из GitHub или из локальных источников (не PyPI), или передавать install requirements.txt, или устанавливать python setup.py, а также работать с Travis-CI с помощью pip версия 18+, поэтому я думаю, что она охватывает множество баз. Я надеюсь, что это будет кому-то полезно, и приношу свои извинения, если другим это покажется не по теме:

В вашем файле requirements.txt, если вы хотите, чтобы люди могли полагаться на ветку разработчика GitHub пакета "foo", например:

scipy>=0.17
matplotlib>=2.0
foo @ git+https://github.com/foo-organization/foo@dev#egg=foo-9999

В вашем файле setup.py:

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

Некоторые скажут, что объединение install_requires и requirements.txt нецелесообразно, и для выпущенной версии я согласен, но я думаю, что это хорошо работает для разработки.

Ах, аккуратно. Итак, если, скажем, пакеты «A» и «B» оба используют этот метод, а пакет «A» перечисляет «B» в качестве зависимости, когда вы переходите к установке «A», он фактически завершает обработку файла requirements.txt для «B». (чего обычно не происходит) - верно?

Я также прочитал этим утром, что install_requires сам по себе был плохим, потому что эти установки были выполнены с помощью setuptools, что означает, что любые параметры pip были проигнорированы, но я не знаю, устарела ли эта информация ...

Я также прочитал этим утром, что install_requires сам по себе был плохим, потому что эти установки были выполнены с помощью setuptools, что означает, что любые параметры pip были проигнорированы, но я не знаю, устарела ли эта информация ...

Вы путаете install_requires с setup_requires .

Ах, аккуратно. Итак, если, скажем, пакеты «A» и «B» оба используют этот метод, а пакет «A» перечисляет «B» в качестве зависимости, когда вы переходите к установке «A», он фактически завершает обработку файла requirements.txt для «B». (чего обычно не происходит) - верно?

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

Привет, ребята, я просто хочу отметить, что путь отказа от поддержки в этом случае был слишком коротким. Я знаю, что ссылки зависимостей уже довольно давно помечены как устаревшие, но URL-адреса PEP 508, которые можно использовать для их замены, не были реализованы до 18.1. В результате оставалось всего 3 месяца для переключения с зависимых ссылок на требования URL, что очень мало для больших проектов.

@rgerkin Привет, я безуспешно пытаюсь следовать твоим инструкциям,

Поиск PACKAGE @ git + ssh: //[email protected] : OWNER / PACKAGE. git @ ФИЛИАЛ
Чтение https://pypi.org/simple/PACKAGE/
Не удалось найти страницу индекса для "ПАКЕТА" (возможно, с ошибкой?)
Индекс сканирования всех пакетов (это может занять некоторое время)
Чтение https://pypi.org/simple/

ПАКЕТ @ git + ssh: //[email protected] : ВЛАДЕЛЬЦА / ПАКЕТ. git @ BRANCH , это в install_requires.

Не могли бы вы понять, почему я получаю это?

@KevinMars Между моим примером и вашим примером есть несколько отличий, включая использование git_ssh, bitbucket, суффикса a.git, именованной ветки и отсутствия тега версии. Возможно, одна или несколько из этих вещей заставляют pip искать по PyPI, а не по вашему URL. Какую версию pip вы используете?

Чтобы отметить кое-что, что я обнаружил: использование setup.py для установки пакета с python setup.py install прежнему требует объявления внешних зависимостей в dependency_links .

В вашем файле setup.py:

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

@rgerkin Спасибо, что поделились этим решением. Но что, если я использую pbr для установки своего пакета Python? Как это адаптировать под pbr?

@KevinMars У меня такая же проблема. Вы когда-нибудь придумали, как исправить? Я пытаюсь потребовать конкретную ветвь частного репозитория bitbucket через SSH.

Я только что понял, что --process-dependency-links больше не существует. Я благодарен сообществу за всю работу. Было выбрано попытка оправдать свое решение бесконечными обсуждениями и лабиринтом закрытия проблем и перенаправления, но я все же думаю, что отказ от этого варианта никому не повредит.