Few ideas. about gddo HOT 6 CLOSED

Thank you for thoughts on GoPkgDoc.

I think that a go get forwarding service is an interesting idea, but it does not need to be part of GoPkgDoc to work or be successful. Kyle Lemons tinkered with a forwarding service, but I think he has set it aside. You might want to get in touch with Kyle.

I am adding search to GoPkgDoc to help people find packages. I want to see how search works before pursuing tags. I am implementing search before tags for a few reasons: I don't need to get involved in defining a tagging standard, search works with packages as they are written today and search will encourage people to write better package descriptions.

I picked "go.pkgdoc.org" because I thought it was the best available name that will work with with Google App Engine. I have no plans to support other languages at this time. There's http://rdoc.info/ for Ruby. Some Python projects use http://readthedocs.org/.

from gddo.

If a tagging standard does gain traction in the Go community, then I will update GoPkgDoc to use it.

cailei recently created a repo for a Go package manager.

from gddo.

If anything, perhaps you could update the API's to include gob encoded synopsis descriptions of the packages per url if they have them?

from gddo.

Are there any pros to using JSON over gobs if gopkg.org (uriel suggested this url as he reserved it for this purpose.) will be built with golang? If i recall correctly you were already storing gobs of data in your database. Could be more efficient and cost effective on both servers if you ask me.

And it would be nice just to know what projects you have in your database to add a link to redirect to the doc if you have it. Im not sure how many go packages in your database are still relevant to post go 1's release. I wouldnt want a go package manager to start off with a bunch of orphaned go projects. :/

from gddo.

yeah if you can filter out the packages that dont have any commits before go 1.0 release, then I can go through and run go fix on the more interesting packages that I come across. And I agree about the JSON thing, though when it comes to google's appengine I am a bit of an optimization nut due to excess can cost money. Though it might not be that big of a deal like you said.

The best way pkgdoc can be used with a separate go package manager is by letting the user specify the category of the packages at upload, and have that information be part of the api json request. Any other information (author, ect) would be useful as well. Also is it possible to request a text only representation of the go docs? If not, will this be supported in the near future?

from gddo.

Yeah, ive looked at most of the code about a week ago, so I have a general idea of the current state of what gopkgdoc can do.

I know you already said how you planned to implement search via querying the documentation before implementing tags (which I agree is the best way forward for now), however im recanting what I suggested about the //TAGS: standard idea, and instead propose allowing the user to select from a drop down list of software genres whenever they submit a package for import. If a genre isnt there, have an option to submit the genre you would like via an "other" option with a text box, then you can review to see if its a genre that you think is reasonable to add.

I thought about tags and came to the conclusion that they are counter productive. First, they can be easily abused, (i.e. tagging your project with tags that are irrelevant to your project for example, just to make your project more visible to users browsing packages), and second, having a list of hundreds of tags to organize thousands of packages isnt that impressive of an improvement imho lol.

I think that search is great and an essential feature, but only caters to people who know what they are looking for. Thats why Im suggesting the software genre idea. Then you can also include that in the api json request, therefore the package manager can use pkgdoc to populate its database with any packages not currently found in the package manager's database.

Of course this is only necessary if you are not apposed to the idea of populating gopm's database with pkg references from pkgdoc. The advantage to this is obviously more packages can be found, however It's perfectly fine just to use pkgdoc for fetching packages documentation without having to actually require the user to go get packages he may not want to download. Its your call.

from gddo.