Hi all - <div><br></div><div>I have uploaded bzlib/UNIFY.plt to planet, hoping to demonstrate what an unified require syntax between collects and planet <b>can</b> look like when we keep it simple.  Please feel free to play with the code. </div>
<div><br></div><div>The example below represents how the syntax can look like (bolded are translated to the planet form): </div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">#lang planet bzlib/unify ;; hoping to see #lang racket here soon instead... </font></div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace"><br>
</font></div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">(require net/url ;; in collects </font></div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">         <b>soegaard/infix</b> ;; from planet ==&gt; (planet soegaard/infix) </font></div>
<div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">         (only-in <b>bzlib/file</b> mtime) ;; ==&gt; (only-in (planet bzlib/file) mtime) </font></div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">         )</font></div>
<div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace"><br></font></div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">(provide (all-from-out net/url ;; in collects </font></div>
<div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">                       <b>soegaard/infix</b> ;; in planet </font></div><div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">                       )</font></div>
<div><font class="Apple-style-span" face="&#39;courier new&#39;, monospace">         )</font></div></div></blockquote><div><br></div><div>Note the main difference is simply the removal of (planet).  </div><div><br></div><div>
bzlib/unify follows a very simple lookup rule (even simpler than I have thought needed originally) - it checks to see if the module-path exists (i.e. net/url or soegaard/infix) via the default (current-module-name-resolver).  If it exists it&#39;s in collects, otherwise wrap the path in `(planet ,module-path).  No additional database lookup is required.  And it does not incur anymore network overhead for planet packages than would have been needed in the first place (just the first-time install). </div>
<div><br></div><div>The package is meant to showcase the viability of the approach and hope to spark further conversations/actions.  Although the concept is doable as a planet module, it should really be incorporated into the core module resolver, since that can make it faster and do error handlings (hiding the planet origin in an error message) better.</div>
<div><br></div><div>A few considerations: </div><div><br></div><div>1 - there might be name clashes between the packages in collects vs in planet.  </div><div><br></div><div>This can be fixed via some or all of the following approach: </div>
<div><ul><li>reserve account names (such as racket or scheme) in planet so others cannot register them that maps to the collects packages so there are no future conflicts  </li><li>if there are already conflicts - determine what to do there on case by case basis, including possibly taking over the account or rename the collect package in question </li>
</ul></div><div>2 - planet packages are always in the form of &lt;account&gt;/&lt;package&gt;.plt, whereas collects do not follow this rule. </div><div><br></div><div>This can either be fixed by changing the planet system to enable top level packages, or change the collects package to follow the same convention. </div>
<div><br></div><div>3 - you (racket core devs) might want a new way to specify module paths instead. </div><div><br></div><div>I am only focused on removing planet from the require/provide syntax, and trying to show that it can be done without a hefty re-architecture so you might decide to incorporate it.  If you do feel new module path formats are warranted, that&#39;s great too.  </div>
<div><br></div><div>Thoughts/comments/questions?  Love to discuss further on this topic. </div><div><br></div><div>Cheers,</div><div>yc</div><div><br><div class="gmail_quote">On Wed, Jul 28, 2010 at 12:33 PM, YC <span dir="ltr">&lt;<a href="mailto:yinso.chen@gmail.com">yinso.chen@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><br>On Wed, Jul 28, 2010 at 1:09 AM, Stephen De Gabrielle <span dir="ltr">&lt;<a href="mailto:stephen.degabrielle@acm.org" target="_blank">stephen.degabrielle@acm.org</a>&gt;</span> wrote:<div class="im">
<br>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
<br>It&#39;s not to early to think about an expanded set of categories<br></blockquote><div><br></div></div><div>One idea is to allow module writers to add to the categories or tags so it becomes a decentralized process, like how blogs do it these days. </div>

<div> </div>On Wed, Jul 28, 2010 at 6:41 AM, Matthias Felleisen <span dir="ltr">&lt;<a href="mailto:matthias@ccs.neu.edu" target="_blank">matthias@ccs.neu.edu</a>&gt;</span> wrote:<div class="im"><br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">

<div><br>On Jul 28, 2010, at 12:26 AM, YC wrote:<br><br>&gt; Other package systems separate the installation step from the import step<br><br></div>Indeed, this is the key design decision separating us from the rest of the world, and it is not clear whether it was a good decision.</blockquote>

<div><br></div></div><div>I personally like the design except for the issues I&#39;ve raised so far, but the disadvantage can be remedied by unifying the require spec syntax between collects and planet. </div><div><br></div>
<div>
On Wed, Jul 28, 2010 at 7:03 AM, Dave Gurnell <span dir="ltr">&lt;<a href="mailto:d.j.gurnell@gmail.com" target="_blank">d.j.gurnell@gmail.com</a>&gt;</span> wrote:<div class="im"><br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><div><br></div></div><div>I&#39;d also like to be able to set up a PLaneT proxy to add in-house libraries in on the top of publicly available libraries from <a href="http://planet.racket-lang.com" target="_blank">planet.racket-lang.com</a>. </div>

</div></blockquote></div></div><div><br></div><div>See my bzlib/planet package.  This is an example where I would like to see the core team take advantage of what&#39;s available on planet directly instead of porting it into core.</div>

<div> </div><div>On Wed, Jul 28, 2010 at 8:20 AM, Neil Van Dyke <span dir="ltr">&lt;<a href="mailto:neil@neilvandyke.org" target="_blank">neil@neilvandyke.org</a>&gt;</span> wrote:</div></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
<br>Most important for me, I&#39;d like to be able to define multiple (what I&#39;ll call for now) repositories (like Debian &quot;apt&quot;).  </blockquote><div><br></div></div><div>FWIW - bzlib/planet is designed for you to facilitate having your own internal packages now.  When multi-repo becomes  available, you can still use bzlib/planet to host your own repo. </div>

<div><br></div><div>On Wed, Jul 28, 2010 at 7:03 AM, Dave Gurnell <span dir="ltr">&lt;<a href="mailto:d.j.gurnell@gmail.com" target="_blank">d.j.gurnell@gmail.com</a>&gt;</span> wrote:<div class="im"><br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><div><br></div></div><div><div>I&#39;d personally be in favour of a leaner core distribution with more code in external packages, so I can choose what I download when I&#39;m only interested in a single web application. </div>

</div></div></blockquote><div><br></div></div><div>Once the collects and planet require syntax are unified - moving the currently-core packages to planet will become a snap. At that time it might even be possible to have &quot;build your own distribution&quot; by picking your own packages.</div>

</div><div><br></div><div><div class="gmail_quote">On Wed, Jul 28, 2010 at 8:20 AM, Neil Van Dyke <span dir="ltr">&lt;<a href="mailto:neil@neilvandyke.org" target="_blank">neil@neilvandyke.org</a>&gt;</span> wrote:<div class="im">
<br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
<br>Then, somehow I would like to prevent packages in the contributed repository from overriding those in the core and internal repositories.  Guaranteeing this through naming, like Java packages, is one way, though that could be cumbersome.<br>

</blockquote></div></div></div><div><br></div><div>Now I think about it, it might make sense to have local repo able to overwrite core repo in case you want to &quot;patch&quot; the core code.  In that case the module resolve I proposed earlier would have to be changed to: </div>

<div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse;color:rgb(51, 51, 51)"><div><ol><li style="margin-left:15px">Try lookup the package in planet cache </li>
<li style="margin-left:15px">If #1 fails, lookup in COLLECTS </li><li style="margin-left:15px">If #2 fails, try lookup the package in planet repo </li></ol><div><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:arial;font-size:small"><div class="gmail_quote">

On Wed, Jul 28, 2010 at 8:20 AM, Neil Van Dyke <span dir="ltr">&lt;<a href="mailto:neil@neilvandyke.org" target="_blank">neil@neilvandyke.org</a>&gt;</span> wrote:<div class="im"><br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">

<br>Package signing to authenticate the packager still seems useful, like it did in the beginning, but that could be revisited in context of whatever other improvements are made.<br></blockquote><div><br></div></div><div>
I like what ASDF has to offer here.  The only thing I would add is that this auth mechanism should be optional (perhaps as a policy per repo). </div>
<div><br></div><div>All my additional 2 cents.  Cheers,</div><div>yc</div><div><br></div><div><br></div></div></span></div></div></span></div></div>
</blockquote></div><br><br>
</div>