Pkg.search() method

[staticfloat]

It would be nice to have some kind of Pkg.search() or somesuch method, to take in a string and search the names of everything in METADATA.jl. I see that we don't have a description field in METADATA, which would mean we couldn't search the description field as well, but this may be something we want eventually, as it's nice to be able to search the names/descriptions of packages without having to find the list on julialang.org.

[johnmyleswhite]

+1

[ViralBShah]

+1

[staticfloat]

@StefanKarpinski Is this something we might want to sneak in for 0.2?

[StefanKarpinski]

Yeah, it's a good idea. If someone wants to take a crack at it, they're welcome to.

[IainNZ]

Re: description field, this is something we could add to https://gist.github.com/IainNZ/6086173

[StefanKarpinski]

I propose a description.md file next to url and a keywords file that contains a key phrase, one per non-blank line, allowing comments in the usual way.

[johnmyleswhite]

I think we're recreating R's DESCRIPTION file piece-by-piece. Why not just take the plunge and mimic everything R asks packages to state?

[StefanKarpinski]

I guess, but I'm not terribly interested mimicking their formats. Also it seems prudent to only add what we feel like we actually need.

[staticfloat]

Taking a look at the relevant R docs isn't a bad idea for inspiration, and the format/content is extremely similar to that of Debian packages, so at least there's some consensus on what is important in a packages metadata.

As far as what we need, however, I feel like we get a lot of stuff for free by using github; We get the maintainer, the the URL and the bug reporter information all for free. I really don't see a need to add anything more than Description (although having a License statement could be nice, but the only reason people might care about that is bundling a distribution of Julia with packages, so I feel might as well let them check out each package individually and save ourselves a bunch of work) and how we implement Description is completely arbitrary. A description.md sounds wonderfully simple to parse, and I'm not really a keywords kind of guy, so I don't care how we do keywords.

All that to say, (in a rather long-winded manner) I +1 @StefanKarpinski's proposal, but I'm open to @johnmyleswhite convincing me that there's more metadata that needs to be gathered here. I would really love for as much metadata as is useful to be collected in METADATA.jl, so that users don't have to hit the network to find out information on the available packages.

[StefanKarpinski]

The nice thing about Markdown is that it is both a good markup format and a good text format – it is basically just a formalization of informal markup people use in text files anyway. The main reason to stick the .md extension on the description.md file is so that github will render it nicely. I would propose further that we stick to the convention of only using markup in description files that works well as both text and markup.

[kmsquire]

As far as what we need, however, I feel like we get a lot of stuff for free by using github; We get the maintainer, the the URL and the bug reporter information all for free.

Right now, all packages are using github (AFAIK), but 1) there's no requirement to do so, 2) as friendly as github is to open source, I don't think it's a good idea to depend on that good will indefinitely (c.f. Sun, which was reasonably friendly to open source, vs Oracle).

[StefanKarpinski]

Yes, we definitely shouldn't rely on GitHub. Having a maintainers file is a better way to go.

[IainNZ]

I've tried to put this in the Julep: https://gist.github.com/IainNZ/6086173
Please review, I'd love to make all these changes at once to avoid confusion.

[staticfloat]

I'm going to close this now, since it seems like http://pkg.julialang.org has grown into something much more useful than this issue would have been.

[IainNZ]

Yes a fresh take (accompanied by a PR!) would be the next place. There is a PR by me out there somewhere that kinda demonstrates this idea anyway.