<div dir="ltr">The mechanism we use to vendor Go dependencies can be somewhat brittle and does not work very well in a number of instances. For some updates, new Go dependencies cause failures during extraction when attempting to capture them in go.vendors.<div><br></div><div>Additionally, the key mechanism we currently use to vendor Go apps, which is disabling Go modules (GO111MODULE=off) is not recommended.  We should try to find a better solution. Gregory Anders proposed one a while back which could vendor deps but still keep Go modules enabled: <a href="https://github.com/macports/macports-ports/pull/10381">https://github.com/macports/macports-ports/pull/10381</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 19, 2022 at 11:28 AM Ryan Schmidt <<a href="mailto:ryandesign@macports.org">ryandesign@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Question regarding this commit:<br>
<br>
<a href="https://github.com/macports/macports-ports/commit/2c8bec5807d23120038f39d292a7e1cad625707d" rel="noreferrer" target="_blank">https://github.com/macports/macports-ports/commit/2c8bec5807d23120038f39d292a7e1cad625707d</a><br>
<br>
Here, a port tfmigrate was updated from 0.3.2 to 0.3.3 and changed to allow it to fetch dependencies at build time.<br>
<br>
What transpired between 0.3.2 and 0.3.3 that made it necessary to allow the port to do its own fetching again? This seems to happen to various go ports with some frequency. What can we do to improve the situation so that this does not become necessary so often?</blockquote></div>