FAQ
The following are suggested semantics for "external" folders where vendored
packages can live. With these semantics no code rewrites are necessary for
the vendor packages and it becomes possible to copy the files directly or
use something like git submodules to graft dependencies into the tree.

https://docs.google.com/document/d/1NS474bvYaZ1SH6dDq0pxzCuXxaQtq56fj8Js4yVVu9E

Suggestions and comments welcome.
-Daniel


--
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

  • Dave Cheney at Feb 23, 2015 at 12:12 am
    I believe this allows multiple packages with the same import path, but different source paths to be present. Ie

    GOPATH/src/a
               /b
               /b/external/c
               /d
               /d/external/c

    If a/a.go imports "c", which copy of c is used ?

    --
    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.
  • Daniel Theophanes at Feb 23, 2015 at 12:42 am
    You would get an import error.
    package "a" would need to import:
    import "a/b/external/c"
    or
    import "a/d/external/c"

    The win comes when ".../external/c" imports another external package. This
    win would allow us to know need to only rewrite packages INSIDE the
    "external" folder. The normal packages that use the external packages would
    still need the full normal import path. I think this would be an important
    win.

    ...

    One thing I saw when working on the cockrochdb code is that it vendors
    etcd's raft package. Now etcd also has a vendor package that contains the
    go.net/context package that cockroach also uses. I'm not sure if this is a
    "problem", but it does seem less then ideal. If etcd broke out raft into
    its own repository and imported it, then raft would also end up in
    external. But then raft would be able to import "golang.org/x/net/context"
    and let etcd repository contain its vendored copy. This would allow other
    users like cockroach to also import "cockroach/external/coreos/raft" and
    "cockroach/external/golang.org/x/net/context". Because raft lives in the
    "external" folder, it can resolve its "golang.org/x/net/context" import
    just fine.

    I hope this clarifies the proposal.
    -Daniel

    On Sun Feb 22 2015 at 4:12:33 PM Dave Cheney wrote:

    I believe this allows multiple packages with the same import path, but
    different source paths to be present. Ie

    GOPATH/src/a
    /b
    /b/external/c
    /d
    /d/external/c

    If a/a.go imports "c", which copy of c is used ?

    --
    You received this message because you are subscribed to a topic in the
    Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit https://groups.google.com/d/
    topic/golang-nuts/yk4Gt--PDBY/unsubscribe.
    To unsubscribe from this group and all its topics, 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.
  • Dave Cheney at Feb 23, 2015 at 9:31 am
    I think I don't understand your proposal. And if it includes the use of
    relative imports, that's a big thumbs down.
    On 23 Feb 2015 11:41, "Daniel Theophanes" wrote:

    You would get an import error.
    package "a" would need to import:
    import "a/b/external/c"
    or
    import "a/d/external/c"

    The win comes when ".../external/c" imports another external package. This
    win would allow us to know need to only rewrite packages INSIDE the
    "external" folder. The normal packages that use the external packages would
    still need the full normal import path. I think this would be an important
    win.

    ...

    One thing I saw when working on the cockrochdb code is that it vendors
    etcd's raft package. Now etcd also has a vendor package that contains the
    go.net/context package that cockroach also uses. I'm not sure if this is
    a "problem", but it does seem less then ideal. If etcd broke out raft into
    its own repository and imported it, then raft would also end up in
    external. But then raft would be able to import "golang.org/x/net/context"
    and let etcd repository contain its vendored copy. This would allow other
    users like cockroach to also import "cockroach/external/coreos/raft" and
    "cockroach/external/golang.org/x/net/context". Because raft lives in the
    "external" folder, it can resolve its "golang.org/x/net/context" import
    just fine.

    I hope this clarifies the proposal.
    -Daniel

    On Sun Feb 22 2015 at 4:12:33 PM Dave Cheney wrote:

    I believe this allows multiple packages with the same import path, but
    different source paths to be present. Ie

    GOPATH/src/a
    /b
    /b/external/c
    /d
    /d/external/c

    If a/a.go imports "c", which copy of c is used ?

    --
    You received this message because you are subscribed to a topic in the
    Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit https://groups.google.com/d/
    topic/golang-nuts/yk4Gt--PDBY/unsubscribe.
    To unsubscribe from this group and all its topics, 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.
  • Dave Cheney at Feb 23, 2015 at 9:32 am
    Yup, rereading what you replied with your proposal admits the same package
    to appear twice in the final binary. This is not acceptable.
    On 23 Feb 2015 11:41, "Daniel Theophanes" wrote:

    You would get an import error.
    package "a" would need to import:
    import "a/b/external/c"
    or
    import "a/d/external/c"

    The win comes when ".../external/c" imports another external package. This
    win would allow us to know need to only rewrite packages INSIDE the
    "external" folder. The normal packages that use the external packages would
    still need the full normal import path. I think this would be an important
    win.

    ...

    One thing I saw when working on the cockrochdb code is that it vendors
    etcd's raft package. Now etcd also has a vendor package that contains the
    go.net/context package that cockroach also uses. I'm not sure if this is
    a "problem", but it does seem less then ideal. If etcd broke out raft into
    its own repository and imported it, then raft would also end up in
    external. But then raft would be able to import "golang.org/x/net/context"
    and let etcd repository contain its vendored copy. This would allow other
    users like cockroach to also import "cockroach/external/coreos/raft" and
    "cockroach/external/golang.org/x/net/context". Because raft lives in the
    "external" folder, it can resolve its "golang.org/x/net/context" import
    just fine.

    I hope this clarifies the proposal.
    -Daniel

    On Sun Feb 22 2015 at 4:12:33 PM Dave Cheney wrote:

    I believe this allows multiple packages with the same import path, but
    different source paths to be present. Ie

    GOPATH/src/a
    /b
    /b/external/c
    /d
    /d/external/c

    If a/a.go imports "c", which copy of c is used ?

    --
    You received this message because you are subscribed to a topic in the
    Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit https://groups.google.com/d/
    topic/golang-nuts/yk4Gt--PDBY/unsubscribe.
    To unsubscribe from this group and all its topics, 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
postedFeb 19, '15 at 10:29p
activeFeb 23, '15 at 9:32a
posts5
users2
websitegolang.org

2 users in discussion

Dave Cheney: 3 posts Daniel Theophanes: 2 posts

People

Translate

site design / logo © 2022 Grokbase