Здравствуйте, vdimas, Вы писали:
V>Это с рождения условие существования.
V>(тут маты, маты, маты...)
А должны быть ссылки, ссылки, ссылки. Увы.

V>Буквально одной извилинкой шевельни — иначе как бы одни и те же программы или либы запросто распространялись что-то под сотню одновременно существующих сегодня независимых пакетных менеджеров и даже несколькими десятками сдохших на сегодня?
Да я-то шевельнул. Не очень понятно, что имеется в виду под "программа не знает о пакете".
В бинаре, понятное дело, никаких следов пакетного менеджера нет. А вот с точки зрения сборки и поставки — сейчас собственно "программа" или "библиотека" и есть пакет.
То есть именно он является результатом труда разработчика. Сборка пакета является частью билд-системы, за которую отвечает собсно исходный автор.
Те случаи, когда опакечивание выполняется посторонними, являются частным случаем — просто исходники собственно кода разрабатывает кто-то другой.
Т.е. вот я являюсь автором пакета, который сам при сборке зависит от чего-то внешнего — например, исходников, вытащенных из гитхаба или битбакета. Или бинарей, которые уже были кем-то собраны для моей целевой архитектуры, но не оформлены для моего пакетного менеджера.

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


V>Поэтому на выходе произведение.
V>А задачей пакетных менеджеров отродясь было давать сумму.
Вы, похоже, не понимаете основную мысль. Дело в том, что для сборки программы или библиотеки, зависящей от проекта А, нужны одни артефакты, а для исполнения — другие.
Ну, на пальцах — в рантайме вам нужен xxx.so файл для вашей зависимости, а при сборке нужен xxx.h файл(ы) (а без .so можно, в принципе, и обойтись).
Или, наоборот — при сборке вы используете .a, который вам в целевой системе нафиг не упал (и в результирующем пакете нет зависимости от xxx.a; она существует только в момент сборки).

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

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

S>>>>Ну, вообще говоря, для воспроизводимости билда лучше указывать фиксированную версию, а обновление зависимостей проводить контролируемо.
V>>>Ес-но, программисту всегда лучше, чтобы юзер его, Великого, не отвлекал своими мелкими потребностями.
V>>>Потому что Он — Творит.
S>>Вижу, до reproducible builds вы ещё не доросли. Ну, ок.
V>В смысле, до перевода выделенного на английский?
V>И добавления усилительного "не доросли"?
V>Синклер, ты хоть отдаешь себе отчёт, что после этих двух эээ... скажем, "махинаций" никакого нового смысла не появилось?
А зачем вам новый смысл, когда вы старый ещё не усвоили?
Давайте я разжую помедленнее, чтобы вы успевали:
1. потребности пользователя вообще ортогональны деталям процесса сборки. Уверяю вас, юзеру абсолютно наплевать, используете ли вы при сборке инкрементальную компиляцию, модули, пакетный менеджер, процедурную генерацию исходников или ещё что-то. Поэтому оправдывать подход "мы там рисуем в зависимостях при билде любой питон новее 2.7" какими-то мифическими потребностями пользователя — очень странно.
2. Я понимаю, вам кажется, что из требования указывать конкретную версию зависимости в билде непосредственно следует прибитие гвоздями конечного продукта ровно к той же версии пакета — но нет, ключевое слово здесь "кажется".
Дело в том, что когда вы, как разработчик, пишете в зависимостях диапазон версий, то инженерная дотошность требует от вас тестирования хотя бы границ этого диапазона. То есть не просто "я думаю, что оно будет работать на версиях не младше 0.9.5, и не работать на версиях не младше 1.0.2", а у вас в процессе сборки проверяется совместимость с версиями 0.9.5. 0.9.6, 1.0.1.
А не просто "дай-ка мне, менеджер пакетов, что-то в этом диапазоне, и собери мой проект с ним".
3. Причины для этого вполне просты и понятны: допустим, вы делаете не так. Вот вы впервые собрали ваш проект с версией 0.9.5 вашей зависимости, и оптимистично написали: Requires xxx >= 0.9.5.
Однажды вы коммитите изменения в репозиторий. Ваш коллега забирает их к себе — упс, у него не работает! Падают тесты. Он расстроен вашей подставой, развлекается откатом изменений и прочими приседаниями. Вы тратите литр кофе, и выясняете: дело в том, что вышла новая версия xxx, 1.0.2, нечаянно стащилась при билде, а ваш коммит тут совершенно ни при чём. Вы добавляете Conflicts xxx >= 1.0.2 и на этом успокаиваетесь. Всё, вроде бы, работает.
Но потом, по мере изменения требований к вашему софту, вы вносите в ваш код изменения, которые отлично работают с версией xxx 1.0.1, но в версиях 0.9.5 и 0.9.6 — нет.
Если вы используете при сборке вот эту любимую вами способность пакетного менеджера оперировать диапазонами, то он вам стащит 1.0.1, и всё успешно соберётся и протестируется.
А вот у того самого юзера до сих пор стоит xxx 0.9.5. И при инсталляции менеджер пакетов не станет её обновлять, т.к. она совместима с вашими requires.
В итоге ваш софт у юзера либо упадёт, либо будет работать неверно.

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

Ничего плохого в этом нет — вон, начинающих студентов вполне устраивает, если программа компилируется. А работает она или нет — это уже не так важно.
Подрастут — начнут делать так, чтобы программа работала корректно хотя бы иногда. Но запросто могут игнорировать коды возврата или возможность вылета исключений.
Потом постепенно приходит понимание, что надо продумывать не только happy path, но и предусматривать различные альтернативные сценарии.

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