Loose specifications allow libraries to avoid unnecessarily causing dependency conflicts for one another. The "pins" file allows application builds to reliably produce the same resolution, time after time.<br><div class="gmail_quote"><div dir="ltr">Steven Clukey via swift-build-dev <<a href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a>> schrieb am Mo. 19. Dez. 2016 um 17:18:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div id="m_4972330145684452300divtagdefaultwrapper" dir="ltr" class="gmail_msg"><div style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt" class="gmail_msg">
<div id="m_4972330145684452300divRplyFwdMsg" dir="ltr" class="gmail_msg">
<div class="gmail_msg"><span style="font-family:verdana,sans-serif;font-size:12pt" class="gmail_msg">> </span><span style="font-family:verdana,sans-serif;font-size:12pt" class="gmail_msg">It’s normal to define your dependencies using a looser interpretation of a version, using things like “~> 1.3” implying
anything from 1.3.0 -> 1.4.0 ( here’s a cute video from Google showing the</span><a href="https://www.youtube.com/watch?v=x4ARXyovvPc" style="font-family:verdana,sans-serif;font-size:12pt" class="gmail_msg" target="_blank"> use-case in CocoaPods</a><span style="font-family:verdana,sans-serif;font-size:12pt" class="gmail_msg"> )
so you would define your dependencies pretty loosely in the manifest ( e.g. package.swift ) but </span><br class="gmail_msg">
</div>
</div>
</div></div></div><div dir="ltr" class="gmail_msg"><div id="m_4972330145684452300divtagdefaultwrapper" dir="ltr" class="gmail_msg"><div style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt" class="gmail_msg"><div class="gmail_msg">
<div dir="ltr" class="gmail_msg">
<div class="gmail_default gmail_msg" style="font-family:verdana,sans-serif"><br class="gmail_msg">
</div>
<div class="gmail_default gmail_msg" style="font-family:verdana,sans-serif"><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt" class="gmail_msg">I understand that most often the manifest version is less specific; I am very specific because in my experience the
swift community is not very stable at this point. I default to strict then loosen as necessary and acceptable. Anyway, </span><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt" class="gmail_msg">I assume that by "looser" you don't mean loose
enough to include versions that are incompatible with the project (intentionally or by negligence, I assume this is bad).</span><br class="gmail_msg">
</div></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div id="m_4972330145684452300divtagdefaultwrapper" dir="ltr" class="gmail_msg"><div style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg">
<div class="gmail_default gmail_msg" style="font-family:verdana,sans-serif">
<p style="font-size:12pt;font-family:Calibri,Arial,Helvetica,sans-serif" class="gmail_msg"><span style="font-size:12pt" class="gmail_msg"></span></p>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<p class="gmail_msg"></p>
</div>
<div class="gmail_default gmail_msg" style="font-family:verdana,sans-serif">> then let the lock/pin file keep track of the exact resolution of those dependencies.</div>
<div class="gmail_default gmail_msg" style="font-family:verdana,sans-serif"><br class="gmail_msg">
</div>
</div></div></div></div></div><div dir="ltr" class="gmail_msg"><div id="m_4972330145684452300divtagdefaultwrapper" dir="ltr" class="gmail_msg"><div style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_default gmail_msg" style="font-family:verdana,sans-serif"><span style="font-family:Calibri,Arial,Helvetica,sans-serif" class="gmail_msg">But the pins file doesn't just "keep track" </span><span style="font-family:Calibri,Arial,Helvetica,sans-serif" class="gmail_msg">of the exact
resolution, it actually forces it. Unless you disable automatic pinning the loose specification in the manifest is basically meaningless - you have an exact version defined by the pins file. Then you need to manage two files, the manifest with some meaningless
loose range and the pins file with the actual version that is being used. Why? Why not just manage the package manifest directly? I still don't see the point.</span><br class="gmail_msg">
</div></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div id="m_4972330145684452300divtagdefaultwrapper" dir="ltr" class="gmail_msg"><div style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg">
<div class="gmail_default gmail_msg" style="font-family:verdana,sans-serif"><br class="gmail_msg">
</div>
<div class="gmail_default gmail_msg" style="font-family:verdana,sans-serif"><span style="font-size:12pt" class="gmail_msg">> </span><span style="font-size:12pt" class="gmail_msg">This tends to make more sense when you have more than a few dependencies.</span><br class="gmail_msg">
</div>
</div></div></div></div></div><div dir="ltr" class="gmail_msg"><div id="m_4972330145684452300divtagdefaultwrapper" dir="ltr" class="gmail_msg"><div style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"></div>
<div class="gmail_extra gmail_msg"><br clear="all" class="gmail_msg">
<div class="gmail_msg">
<div class="m_4972330145684452300gmail_signature gmail_msg">
<div dir="ltr" class="gmail_msg">I would actually think it the opposite. If I have a project with many dependencies constantly updating and changing I would want to be as strict as possible with the versions that are allowable. I believe many other people would too, this is
why the pins file exists to begin with. It allows very specific management of the versions of the dependencies in a way that the package manifest somehow (I do not yet understand this somehow) cannot.</div></div></div></div></div></div></div></div><div dir="ltr" class="gmail_msg"><div id="m_4972330145684452300divtagdefaultwrapper" dir="ltr" class="gmail_msg"><div style="color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_msg"><div class="m_4972330145684452300gmail_signature gmail_msg">
<div dir="ltr" class="gmail_msg"></div>
<div dir="ltr" class="gmail_msg"><br class="gmail_msg">
</div>
<div dir="ltr" class="gmail_msg"><br class="gmail_msg">
</div>
<div dir="ltr" class="gmail_msg">Steven</div>
<div dir="ltr" class="gmail_msg"><br class="gmail_msg">
</div>
<div dir="ltr" class="gmail_msg"><br class="gmail_msg">
</div>
</div></div></div></div></div></div></div>
_______________________________________________<br class="gmail_msg">
swift-build-dev mailing list<br class="gmail_msg">
<a href="mailto:swift-build-dev@swift.org" class="gmail_msg" target="_blank">swift-build-dev@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br class="gmail_msg">
</blockquote></div>