<meta charset="utf-8"><div class="gmail_quote"><br class="Apple-interchange-newline">On Wed, Jul 28, 2010 at 1:09 AM, Stephen De Gabrielle <span dir="ltr"><<a href="mailto:stephen.degabrielle@acm.org">stephen.degabrielle@acm.org</a>></span> wrote:<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's not to early to think about an expanded set of categories<br></blockquote><div><br></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"><<a href="mailto:matthias@ccs.neu.edu">matthias@ccs.neu.edu</a>></span> wrote:<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 class="im"><br>On Jul 28, 2010, at 12:26 AM, YC wrote:<br><br>> 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>I personally like the design except for the issues I'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"><<a href="mailto:d.j.gurnell@gmail.com">d.j.gurnell@gmail.com</a>></span> wrote:<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'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><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'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"><<a href="mailto:neil@neilvandyke.org">neil@neilvandyke.org</a>></span> wrote:</div></div><div class="gmail_quote"><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'd like to be able to define multiple (what I'll call for now) repositories (like Debian "apt"). </blockquote><div><br></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"><<a href="mailto:d.j.gurnell@gmail.com">d.j.gurnell@gmail.com</a>></span> wrote:<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'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'm only interested in a single web application. </div>
</div></div></blockquote><div><br></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 "build your own distribution" 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"><<a href="mailto:neil@neilvandyke.org">neil@neilvandyke.org</a>></span> wrote:<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><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 "patch" the core code. In that case the module resolve I proposed earlier would have to be changed to: </div>
<div><span class="Apple-style-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 class="Apple-style-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"><<a href="mailto:neil@neilvandyke.org">neil@neilvandyke.org</a>></span> wrote:<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>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>