I'm not sure I'm quite getting what you want, but is using 'planet url' (via the planet commadline tool) sufficient?
The .plt files are all there, but they aren't in a place that is served by the web server. I looked quickly into changing that; it isn't trivial, but it is certainly doable if 'planet url' isn't sufficient. Robby On Tue, Jan 19, 2010 at 1:08 PM, YC <[email protected]> wrote: > > On Tue, Jan 12, 2010 at 11:52 AM, Robby Findler > <[email protected]> wrote: >> >> > 3 - the package-source url >> > (http://planet.plt-scheme.org/package-source/) >> > used to be visible with package directories but now it is forbidden. >> > This >> > page provides a point for a crawler to mirror the packages. Can we make >> > it >> > (and the children path) visible again? >> >> I think I've fixed that, thanks. > > Okay - now that I have sometime playing with it, it appears that the current > package-source is insufficient for mirroring purposes. > > While I now can crawl the repository, I then would have to pass the right > "lang" version in order to download the package via the planet API - this > would require guessing, or iterate through all lang versions across all > paths, which is obviously inefficient. > > Is there a possibility that the underlying package can be exposed via some > url so they can be mirrored without using the lang value? > > I am assuming the packages are held somewhere on the hard drive that are > closely related to the package-source directory, so I am assuming exposing > the link is a minimal work. If this assumption is not true, let me know, > and I will implement the brute force approach until planet can be adjusted > for lang-less download. > > Thanks, > yc _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
