<br><br><div class="gmail_quote">On Tue, Jan 8, 2013 at 7:01 AM, Jonathan Lange <span dir="ltr"><<a href="mailto:jml@canonical.com" target="_blank">jml@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 8 January 2013 12:58, John Arbash Meinel <<a href="mailto:john.meinel@canonical.com">john.meinel@canonical.com</a>> wrote:<br>
...<br>
<div class="im">> [1]  IIRC it does this by playing games with site.py configuration at<br>
> runtime, and using a custom 'py' script. It removes all default search<br>
> paths, and sets each path manually. One could imagine a build tool<br>
> that built up GOPATH based on explicit locations for versions of<br>
> dependencies.<br>
><br>
<br>
</div>Correct.<br>
<br>
If you squint hard enough, buildout as Launchpad uses it is a way of<br>
emulating static linking for Python.<br>
<br>
jml<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>to me the ideal way for this would be something like virtualenv for go. where by GOPATH is set manually and a requirements.txt file could specify vcs revisions against each pkg for use when fetching via go get or some augmented version of the same. That avoids the need for lock step branching and source modification for frozen release.</div>
<div><br></div><div>-k</div><div> </div></div>