Something like the Planets of Racket-lang? Should be able to install offline, though~
2011/4/18 Noah Lavine <noah.b.lav...@gmail.com>: > Hello all, > > I'm afraid this email is coming much later in the planning process > than it should, and quite possibly we won't be able to do any of this > for SoC, and that's fine with me. But I was thinking about what we > could do that would be a "killer feature" for Guile's CPAN - something > that isn't already done by apt-get, dorodango, and every other package > manager. One answer is that having a big collection of Guile packages > *is* a killer feature, but we could have an apt repository of those if > we wanted one. > > I think the answer is that the killer feature for a large repository > of packages is having the ability to painlessly bundle a piece of > software you've been writing and all of its dependencies in one > easy-to-install thing for users. After all, it's easy when you're > developing on your own machine to download a bunch of packages and use > them to do whatever you need to do, but if you then want to send that > to other people, you've got to collect the source code (or at least > .go files) for all of them, put them in a folder, make sure the > load-path will work out, and then most importantly, do all of that > again every time a new version of one of your dependencies comes out. > I think the feature that is missing is the ability to say "take my > software and package it so that its only external dependency is > POSIX", or something similar. > > The implementation of such a thing isn't especially deep, but I bet > there will be a lot of little things that need to be done just right > for it to work. I think this could be a part of a package manager that > also does the other things Paul was listing. > > How does this idea sound? > > Noah > > On Tue, Apr 12, 2011 at 11:01 PM, Paul Raccuglia <pra...@gmail.com> wrote: >> Hi. Since the idea of creating something like CPAN is something folks >> wants, I figure it would be good to collect as many thoughts and >> information as possible in one place. >> >> (I'd also appreciate links to relevant threads) >> >> My thoughts, specifically, were for the client to be fairly similar in >> function to apt-get. (from the user's perspective) >> The core commands would be: >> >> INSTALL package_name -- queries a server (set in configuration >> files), gets an absolute link to the package, and a list of >> dependencies. Downloads the package, and then any dependencies, and >> takes care of unpacking, verifying, compiling, storing, etc. anything >> that needs to be done. The package would have to have meta-data >> attached in some fashion. >> >> REMOVE package_name -- just has to remove all the relevant files, and >> clean up any references to the package in the storage system. May want >> to check dependencies and alert the user. >> >> UPDATE [package_name] -- could be called to check all packages (by not >> specifying a package name) or to update a specific package. Warn the >> user of any dependencies that could be broken. >> >> My thought was that the package manager could, itself, be a package >> (but, hopefully, one that would be included by default). I wouldn't >> imagine that the current code base would need to be modified a whole >> lot. >> >> I was thinking that most of this project could be written in Guile. >> Does that make sense? >> >> Some thoughts I heard were: >> using stowfs to handle storing the packages intelligently >> use dorodango to handle most of the acquisition >> >> >> For the server design: >> I was envisioning a website to navigate packages (like >> http://packages.debian.org/stable/). My thought is to do everything >> over HTTP (seems like that would work well with Dorodango). Doesn't >> seem like a hugely complicated issue? >> >> Questions about the server: >> How would the central repository be maintained? Give trusted >> developers the ability to make changes to their personal packages at >> will? >> How will packages be nominated / selected for inclusion? >> >> >> That's all I can think of, right now. I'm sure there's more but I want >> to start a discussion. Thanks, >> Paul R >> >> > > -- CrLF.0710
