Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core/coreapi package extracted to interface-ipfs-core repo #3176

Closed
1 task done
ghost opened this issue Sep 2, 2016 · 2 comments
Closed
1 task done

core/coreapi package extracted to interface-ipfs-core repo #3176

ghost opened this issue Sep 2, 2016 · 2 comments
Labels
help wanted Seeking public contribution on this issue status/deferred Conscious decision to pause or backlog topic/core-api Topic core-api
Milestone

Comments

@ghost
Copy link

ghost commented Sep 2, 2016

See ipfs-inactive/interface-js-ipfs-core#66

Dependencies:

@ghost ghost added the topic/core-api Topic core-api label Sep 2, 2016
@ghost ghost added this to the IPFS Core API milestone Sep 2, 2016
@whyrusleeping whyrusleeping added the help wanted Seeking public contribution on this issue label Sep 14, 2016
@flyingzumwalt flyingzumwalt added the status/deferred Conscious decision to pause or backlog label Sep 26, 2016
@ghost ghost self-assigned this Nov 2, 2016
@whyrusleeping
Copy link
Member

@lgierth update here?

@Mr0grog
Copy link
Contributor

Mr0grog commented Jun 8, 2018

Moving a relevant conversation here from ipfs-inactive/docs#68

@Mr0grog:

The “JS & Go Libraries” section that links to the ipfs/interface-ipfs-core docs really only covers the JS library. It appears as though it was intended to cover Go, too, but what I’ve uncovered from asking around is that many folks aren’t actually working towards that, let alone are even sure it totally makes sense…

…If the Go bits are never really going to be documented in the interface docs, we should be clear about that and remove all the references to Go. We should also figure out if this is the best way to document that API rather than just test it.

@olizilla:

Can we fix that? Who do we need to convince @diasdavid @whyrusleeping?

@magik6k:

Yep, coreapi is what will eventually be the 'go part' of interface-ipfs-core. Currently coreapi lives in go-ipfs repo because it's easier to develop it there. The roadmap is in #4498

To add a little more context, I was told in a few private conversations that documenting the Go CoreAPI in interface-ipfs-core was unlikely to really happen because:

  • The effort is going super slow
  • It’s unlikely to exactly match JS or the “commands” (in the CLI/HTTP sense). For example, it exports additional utilities like ResolveNode(), ResolvePath(), string.ParsePath(), etc.
  • A general feeling that maintaining that doc was too much of a pain and a keeping-things-in-sync problem, and that this was better achieved through generating docs from the source here in ipfs/go-ipfs.

It may be that this was really a “sigh, this is just the unfortunate state of things” opinion and not an official position, but I am interested in making sure we are taking a pragmatic approach that best serves the users of these tools. Things like these empty specs are a real problem. I don’t recall if it was somewhere in a GitHub issue, on discuss.ipfs.io, or on IRC, but I found at least one person thinking there was no way to use the API in Go or use go-ipfs as a library because all the Go entries in interface-ipfs-core say “WIP.” I’m all for trying to get things cohesive and unified, but we need to paint a realistic picture for the community about what’s actually happening (not just what we aspire to) and always communicate status and timeframe wherever things are left in a halfway state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Seeking public contribution on this issue status/deferred Conscious decision to pause or backlog topic/core-api Topic core-api
Projects
None yet
Development

No branches or pull requests

4 participants