FAQ
Hi.

In a project I need to find a package by its import path.
It seems that the only API available is via the go list command, so I'm
using it.

Here are some problems I found:

- The go list help documents the Package type, however some two fields have
the PackageError type, and this is not documented.

- What is the reason why the Package type documented in the go list command
is not exported from the go/build package?

- I my command I need to detect if the <import path> specified by the user
exists, and I do it by checking if JSON decoder returns EOF.
   However I would like to print a custom error message depending on <import
path>. If it is a pattern I want to report "%q matched no package",
otherwise "cannot find package %q".
   How can I check if import path is a pattern? strings.Index("...") ?

- What is the reason why the functionality of go list is not available as
an API in the go/build package?


Thanks Manlio

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Andrew Gerrand at Jan 18, 2016 at 10:25 pm

    On 19 January 2016 at 08:03, Manlio Perillo wrote:

    Hi.

    In a project I need to find a package by its import path.
    It seems that the only API available is via the go list command, so I'm
    using it.

    Here are some problems I found:

    - The go list help documents the Package type, however some two fields
    have the PackageError type, and this is not documented.
    This is an omission. Please file an issue <https://golang.org/issue/new>.

    - What is the reason why the Package type documented in the go list command
    is not exported from the go/build <https://goto.google.com/build> package?
    The Package type documented by cmd/go is not the same as the Package type
    in the go/build <https://goto.google.com/build> package. The cmd/go tool
    uses go/build <https://goto.google.com/build> for some things, but does a
    lot more than just go/build <https://goto.google.com/build> alone.

    - I my command I need to detect if the <import path> specified by the user
    exists, and I do it by checking if JSON decoder returns EOF.
    However I would like to print a custom error message depending on
    <import path>. If it is a pattern I want to report "%q matched no
    package", otherwise "cannot find package %q".
    How can I check if import path is a pattern? strings.Index("...") ?
    The presence of ... is the only way an import path can be a wildcard
    pattern, so strings.Contains(path, "...") is fine.

    - What is the reason why the functionality of go list is not available as
    an API in the go/build <https://goto.google.com/build> package?
    Because the functionality was authored as part of the cmd/go tool. It was
    never designed to be a public-facing API. One reason for this is that by
    keeping such interfaces internal to the tool, we are free to change those
    internals without breaking other users. It's possible that with the benefit
    of the knowledge and experience we have today, we might have structured the
    go tool differently.

    Andrew

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Manlio Perillo at Jan 18, 2016 at 10:43 pm

    On Mon, Jan 18, 2016 at 11:24 PM, Andrew Gerrand wrote:
    On 19 January 2016 at 08:03, Manlio Perillo wrote:

    Hi.

    In a project I need to find a package by its import path.
    It seems that the only API available is via the go list command, so I'm
    using it.

    Here are some problems I found:

    - The go list help documents the Package type, however some two fields
    have the PackageError type, and this is not documented.

    This is an omission. Please file an issue.
    Done, https://github.com/golang/go/issues/14007.
    - What is the reason why the Package type documented in the go list
    command is not exported from the go/build package?

    The Package type documented by cmd/go is not the same as the Package type in
    the go/build package. The cmd/go tool uses go/build for some things, but
    does a lot more than just go/build alone.
    - What is the reason why the functionality of go list is not available as
    an API in the go/build package?

    Because the functionality was authored as part of the cmd/go tool. It was
    never designed to be a public-facing API. One reason for this is that by
    keeping such interfaces internal to the tool, we are free to change those
    internals without breaking other users. It's possible that with the benefit
    of the knowledge and experience we have today, we might have structured the
    go tool differently.
    The fact is that, as the documentation in cmd/go/pkg.go source file
    says, the definition of the Package struct is subject to the Go
    compatibility promise (AFAIK).
    This make it safe to put it in the standard library. The problem may
    be **where** to define it. You are right that go/build is not the
    right place; I forgot that it has a different definition of Package
    (every tool seems to have a different definition of Package).
    But it is not a big problem; it is just inconvenient having to copy
    and paste from the shell to the editor.


    Thanks Manlio

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Manlio Perillo at Jan 22, 2016 at 8:52 pm

    Il giorno lunedì 18 gennaio 2016 23:26:01 UTC+1, Andrew Gerrand ha scritto:

    [...]
    - What is the reason why the functionality of go list is not available as
    an API in the go/build <https://goto.google.com/build> package?
    Because the functionality was authored as part of the cmd/go tool. It was
    never designed to be a public-facing API. One reason for this is that by
    keeping such interfaces internal to the tool, we are free to change those
    internals without breaking other users. It's possible that with the benefit
    of the knowledge and experience we have today, we might have structured the
    go tool differently.
    I just checked the golint tool, and it **reimplements** all the logic of go
    list.
    Isn't this just crazy?


    Thanks Manlio

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Andrew Gerrand at Jan 25, 2016 at 2:46 am
    You mean import.go
    <https://github.com/golang/lint/blob/master/golint/import.go>? It's not a
    new implementation, it's just a copy of the code.
    I don't think that's crazy. Copying code is a reasonable approach.

    There's an open issue <https://github.com/golang/go/issues/8768> to export
    the code, but no action so far.
    On 23 January 2016 at 07:52, Manlio Perillo wrote:

    Il giorno lunedì 18 gennaio 2016 23:26:01 UTC+1, Andrew Gerrand ha scritto:
    [...]
    - What is the reason why the functionality of go list is not available as
    an API in the go/build <https://goto.google.com/build> package?
    Because the functionality was authored as part of the cmd/go tool. It was
    never designed to be a public-facing API. One reason for this is that by
    keeping such interfaces internal to the tool, we are free to change those
    internals without breaking other users. It's possible that with the benefit
    of the knowledge and experience we have today, we might have structured the
    go tool differently.
    I just checked the golint tool, and it **reimplements** all the logic of
    go list.
    Isn't this just crazy?


    Thanks Manlio

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 18, '16 at 9:03p
activeJan 25, '16 at 2:46a
posts5
users2
websitegolang.org

2 users in discussion

Manlio Perillo: 3 posts Andrew Gerrand: 2 posts

People

Translate

site design / logo © 2021 Grokbase