<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On 2016-11-28, at 09.44, David Sweeris via swift-build-dev <<a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a>> wrote:<br class=""><div><div class=""><br class="Apple-interchange-newline"></div><blockquote type="cite" class=""><div class=""><div style="font-family: SFUIText-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Does the pinning info have to be in an optional file? Would it be better to have it be an optional part of the manifest? There'd be one less file to carry around.</div></div></blockquote><br class=""></div><div>One conceptual reason to keep the pinning information in a separate file is that, while a manifest is a single source of truth for the inherent dependencies of a single package, a pin file expresses contextual constraints about a package graph as a whole. The fact that the information in the pin file is context-based also leads to a second big reason to keep them separate: it would be perfectly reasonable to have multiple pin files for the same top-level package, for example in the case of CI systems that should test against the latest release versions of dependencies as well as the latest pre-releases (for example). There would need to be additional facilities for this to work well, but the design should not preclude the use of multiple pin files in the future, and storing multiple sets of pinning info in the manifest would make that harder.</div><div><br class=""></div><div>Anders</div><div><br class=""></div></body></html>