about the subject. Maybe someone that followed the conversation can
tell me where I am wrong.
> For CHICKEN, we already have an s-expression based list of eggs, it's
> what our own infrastructure uses:
> http://bugs.call-cc.org/browser/project/release/4/egg-locations and
> http://bugs.call-cc.org/browser/project/release/5/egg-locations
OK, I didn't know that either. Seems you also have files like this:
<https://bitbucket.org/DerGuteMoritz/zmq/raw/master/zmq.meta> to get the
description (synopsis) for each package.
>> I don't know if there would be a reliable way to include information about
>> implemented SRFIs in there. Maybe there could be a standardized package
>> metadata file.
> I think that's a bit of overkill, TBH. And different implementations
> will use different formats anyway
Yes, it would be nice but it would be a lot of work except if some of us have the
time to patch existing software. See way below for an alternative approach.
(unless there will be a single package manager to rule them all).
That is unlikely to happen, and I adventure myself to say that at this point it might
not be schemey or scheme spirit where standards come and go and people
pick what they want from them. That being said, I am hopeful it might change with
r7rs.
I believe a single package _index_ containing everything would be a boon
to the growth and vitality of the community.
That is where I had the idea to use a search engine to do this "indexing" job.
This would allow to index existing documentations, papers or codes without
much change in the existing infrastructures.
What I have in mind a specialized search index where only things scheme
are indexed so that it can serve as a central point where schemers can go
to look for scheme things.
I believe it integrates well with the decentralized / distributed nature of scheme
development.
(It would especially help
smaller implementations and lesser known/abandoned packages to be
discovered more often. It could also help with duplication of effort - I
have a couple of times missed some existing packages that could have
been used as-is, or be used as a basis for new development instead of
starting from scratch.)
A single package _manager_ may not be technically or socially possible
(due to R6RS vs R7RS differences, Unix vs Windows, "purely functional"
vs "classic" builds and other things). But if there is a single index
with listings and search across all of them, it could just show the
command lines for installing the packages from whatever package managers
they are available from. That would be almost as easy for users as
having just one Scheme package manager.
But the package index would definitely be the nicer to use the more
information it can include. Common Lisp now has <http://quickdocs.org/>
to go with their Quicklisp package manager.
Like that idea. I think that a search engine is more general and covers more
use cases. Also I believe a search engine is easier to setup.
That site offers an awesome
interface for people to discover packages and even browse their
documentation. It's even nicer than the sites for more popular languages
like CPAN and Clojure. Something like that for Scheme would be great and
I think we should aim for that level of usability (in 5-10 years young
programmers are probably going to expect that level of usability). It
may take a few years to reach that goal but there are always little
things we can do here and there to help us along towards that goal :)
FWIW, I have implemented a search engine in scheme. It sure can
be improved but the basics are there: indexing and querying.
If people are willing to support that kind of effort and actually use it. I will
setup an instance and we will be able to start on gathering and indexing
scheme links.