- 1
- 2
- 3
- 4
- 5
- 6
- 7
Whether or not you check in your Pods folder is up to you, as workflows vary from project to project. We recommend that you keep the Pods directory under source control, and don't add it to your .gitignore
Benefits of checking in the Pods directory
After cloning the repo, the project can immediately build and run, even without having CocoaPods installed on the machine. There is no need to run pod install, and no Internet connection is necessary.
The Pod artifacts (code/libraries) are always available, even if the source of a Pod (e.g. GitHub) were to go down.
The Pod artifacts are guaranteed to be identical to those in the original installation after cloning the repo.
зы: почему эпл не сделает свой нормальный пекедж и депенденси менеджер? почему какое-то рубийное наколенное до сих пор существует?
Жалко, что не один из них не рабочий.
А так Carthage намного проще и лучше, если base language это Свифт, конечно.
ну Carthage хоть на свифте писан
> лишнего
Ричард Столлман смотрит на тебя как на говно.
Но ты всегда можешь по первому требованию получить сырцы, вот в чем поинт Столлмана
Что, кстати, не означает, что ты должен сырцы раздавать всем подряд на гитхабе. Можно только тем, кому продал свой софт.
Fee to download source may not be greater than the fee to download the binary.
Т.е. оно всегда качает последнюю версию, даже на коммит лочиться не умеет?
слона-то я и не приметил
три раза собираешь проект на CI -- три раза разные билды получаюится
но на самом деле там можно указать версия конечно
Поэтому остальные разработчики могут выполнить pod install и те же самые версии библиотек
Я вообще недавно узнал, что у них в доках такая рекомендация. Потому очень удивлялся, что в проекте, который щас надо поддерживать, зависимости были прямо в гите. Нуашо, в доке ж написано
у кого-то и рубей может не быть
You don’t, macOS comes with a Ruby 2.0.0 or newer pre-installed in /usr/bin/ruby which are our baselines and these should work out of the box.
https://guides.cocoapods.org/using/faq.html
Шах и мат, аметисты
Но вообще, идея не ломать свой проект, когда какому-то мудаку захочется удалить свой очередной left-pad, кажется здравой.
Чтоб если кто-то создал X и протестировал с определёнными версиями зависимостей, по умолчанию пользователю приходило бы всё это в неизменном виде, не важно, кто там что удалил или сломал в пакетах, от которых зависит X.
Меня шмонай ты, вертухай,
Да загляни под юбочку,
Да посмотри на булочки.
Понюхай попку носиком,
Прикинься, киса, пёсиком,
Вот в этом вся и разница,
Кто хочет, а кто дразнится.
©Любимая группа мамки админа
Думал, left-pad - это совсем другая история - вот и привёл в эту пример :)
Когда пробуешь пособирать какой-нибудь Haskell через cabal, поневоле хочется начать вендорить зависимости. И то сейчас уже получше, раньше вообще ад был, постоянно всё ломалось.
Кстати, вон и СёмаРиал выше о том же глаголит.
Неплохая цена за то, чтобы left-pad не потерялся
Кстати, есть опыт внедрения/использования у кого-то?
бесплатный
норм
Оно ж бесплатное. Работает хорошо, нареканий нет.
>Nexus Repository OSS
>The world's only repository manager with FREE support for popular formats.
https://www.sonatype.com/hs-fs/hubfs/SON_NexusRepoOSS_table@2x%20(1).png?t=15 20018921654&width=540&name=SON_NexusRepo OSS_table@2x%20(1).png
Тут прямо целая сравнительная табличка нагуглилась: http://binary-repositories-comparison.github.io/
Для 90% энтерпрайзного говнища - вполне адекватное описание.
Да хуй с ним, с удалением. А если бы туда вредоносный код попал?
а обновляться как?)
Зеркалировать надо еще и для того, чтобы у тебя по 150 раз в день на CI и машинах разрабов не качались одни и те же 200 мегабайт
Ну урл исходной репы там, скорее всего, тоже записан. Так что можно и обновиться (если это реально нужно).
писька в том, что в уважающем себя JS прокете (будь то клиент или сервер) зависимостей обычно штук триста (включая т.н. peer -- транзитивные). Можно сломаться все ревьюить:)
Ну в целом мысля про хеш понятна:
она гарантирует что для версии [email protected] всегда приедет один и тот же пакет
Статья на швабре было недавно про это.
Можно заранее подготовить бекдор, а потом следующим комитом без палева его активировать.
Нахуя её вообще качать?
Хотя если ты умеешь package management, то наверняка ты умеешь и uglify/webpack/browserify итд
Я о таком не слышал, наверное могут если лицензжия не позволяет
Вот: http://govnokod.ru/23850#comment403216
А код парсится нормально.
code и pre в p.
Скорми текст в валидатор, только поменяй заголовок на
<!DOCTYPE html>
<html >
чтобы был html5 потому что xhtml strict заебет ошибками
https://s13.postimg.org/cp8pj4rnr/image.png
Ни в кого нельзя: pre блочный, его можно только в div.
В span можно только инлайновые.
В p вообще можно только текст и инлайновые
Невалидный код у страйко, нельзя <pre> в <p>
Я глупость сморозил. На самом деле при изменении апстрима rebar сам изменит lock-файл, и это будет заметно в диффе.
npm тоже умеет .lock, кстати
и вот как тут выяснили и кокоаподс ябловый умеет
правда мне не очень понятно как это сделать если пакеты качаются по https
З.Ы. Имхо, HTTPS тут совершенно лишний и только создаёт иллюзию безопасности.
бог с тобой! Без HTTPS я тебе насру в hosts или в твой DNS и ты будешь качать все зависимости с моего сайтика, а что я туда положу будет зависеть от настроения
Ну вот хеш спасает конечно, но с новыми как бывть?
Автору придётся доверять (ну или ревьювить его код каждый раз). А от сервера и прочих посредников спасёт GPG подпись автора. В итоге HTTPS в этой схеме только для красоты остаётся.
Если репу не взломали, значит ты знаешь что новую версию пакета (на которую ты обновляешься) положил туда автор пакета. Если автор, например, Резиг, то ты знаешь что он не мудак, и пакет не будет тебе гадить.
Если нет HTTPS то тебе приходится полагаться на то, что админ DNSа, которым ты сейчас пользуешься, не мудак.
А шансы на это не очень велики, особенно в кафе или аэропорту.
Не админ сервера с репой?
Не взломавший сервер с репой?
Не взломавший пароль автора от репы?
А если у меня уже есть GPG подпись автора - то мне похуй на все эти HTTPS, они ничего нового не дадут.
Если это www.npmjs.com (или где там у них главный реп) то я почти наверяка уверен что их не сломали.
Блин! Я согласен что без хешкода много дыр, но все таки HTTPS тут явно не лишний: он сразу отсекает наиболее вероятный и простой способ взлома.
Опять таки все упирается в отсутствие https (передайте борманду за вон той партой). Не важно как тебя пидарнут: через arp spoofing-ли, через DNS, или через сломанный роутер. Важно что канал между тобой и местом, где терминируется tls надо рассматривать как НЕ безопасный.
Кстати, параноки могут привязывать мак адреса к порту или ключу в случае wifi/eap