<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><br></div><blockquote type="cite"><div>The PyPI discussions seem to be tending toward mixing the window dressing with the framing, to use a building analogy, and what that will result in is a weak frame and ugly windows. &nbsp;A building that slowly (or quickly) falls down under its own weight, and looks bad doing it.</div></blockquote><blockquote type="cite"><div><br>I think that splitting <br><br><span class="Apple-tab-span" style="white-space:pre">        </span>&gt; package storage and pointers to off-repository storage (for those who don't upload to PyPI)<br><span class="Apple-tab-span" style="white-space:pre">        </span>&gt; metadata about the stored packages<br><span class="Apple-tab-span" style="white-space:pre">        </span>&gt; tools for creating stored packages<br><span class="Apple-tab-span" style="white-space:pre">        </span>&gt; tools for retrieving stored packages<br><span class="Apple-tab-span" style="white-space:pre">        </span>&gt; tools for installing packages<br><br>would go a long way towards unobfuscating this whole discussion<br></div></blockquote><div><br></div><div>Is not what sourceforge already provide?&nbsp;Susebuild server could provide support to complete the loop:</div><div><br></div><div><blockquote type="cite"><div><span class="Apple-tab-span" style="white-space: pre; ">        </span>&gt; package storage and pointers to off-repository storage (for those who don't upload to PyPI)<br></div></blockquote></div><div><blockquote type="cite"><div><span class="Apple-tab-span" style="white-space: pre; ">        </span>&gt; metadata about the stored packages<br></div></blockquote></div><div>1 sorce/project management/metadata (sourceforge)</div><div><br></div><div><blockquote type="cite"><div><span class="Apple-tab-span" style="white-space: pre; ">        </span>&gt; tools for creating stored packages<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>&gt; tools for retrieving stored packages<br></div></blockquote></div><div>2 continuous build binary (susebuild)</div><div>3 package repositpry download (with programmatic api) on susebuild</div><div><br></div><div><blockquote type="cite"><div><span class="Apple-tab-span" style="white-space: pre; ">        </span>&gt; tools for installing packages<br></div></blockquote>yum/yast/apt etc tools are already there for linux o and supported on opensuse build server</div><div><br></div><div><br></div><div>Regards,</div><div>Antonio</div><div><br></div><div><div>If you can forgive my self promotion I've used this approach in a project of mine (<a href="http://pyvm.sf.net">pyvm.sf.net</a>): is not completely automated, but it fits the bill point by point: moreover it has support for unitesting too.</div><div><br></div></div><br><blockquote type="cite"><div><br>Yes, I'm sure someone will disagree with some fine-point of that division but isn't that what &nbsp;woodshedding is all about?<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><br></div><div><br></div></body></html>