FAQ
A few questions regarding the interaction between multiple GOPATHs and
dependency tracking:

Say I have two GOPATHs: GOPATH=/gp1:/gp2
For all questions below, I will be building or installing a binary location
in /gp2, whose package path is "myprog";
"myprog" will depend on other packages found both in /gp1 and /gp2.

Questions:

Q1:
Consider the steps:
(1) In /gp1, install all packages, via e.g. "go install ..."
(2) Modify the source of some package in /gp1
(3) Go to /gp2, and
(3a) Build "myprog" via "go build", or
(3b) Install "myprog" via "go install"

In either case, (3a) or (3b), will the modifications in step (2) be
reflected in the built binary?

Q1-variation:
If in step (1) we installed only some of the packages in /gp1, but not all
that are needed by "myprog", then:
(i) If we used (3a), true or false: The installed packages in /gp1 will be
used, the others will be built (for the sake of "myprog") but not installed.
(ii) If we used (3b), true or false: The installed packages in /gp1 will be
used, the others will be built but not installed. (Same as above.)

Q2:
Is it OK, to have packages in /gp1 and /gp2 that share some (but not all)
of their package paths, e.g.
"lib/pkg1" in /gp1, and
"lib/pkg2" in /gp2

Q3:
And just to confirm:
If within any gopath (/gp1 or /gp2) a package directory is a symbolic link
to an external directory, then
dependency tracking is unpredictable.

Thanks
Petar

--

Search Discussions

  • Kyle Lemons at Nov 12, 2012 at 5:56 pm
    Did you try it out?
    On Sat, Nov 10, 2012 at 7:05 AM, Petar Maymounkov wrote:

    A few questions regarding the interaction between multiple GOPATHs and
    dependency tracking:

    Say I have two GOPATHs: GOPATH=/gp1:/gp2
    For all questions below, I will be building or installing a binary
    location in /gp2, whose package path is "myprog";
    "myprog" will depend on other packages found both in /gp1 and /gp2.

    Questions:

    Q1:
    Consider the steps:
    (1) In /gp1, install all packages, via e.g. "go install ..."
    (2) Modify the source of some package in /gp1
    (3) Go to /gp2, and
    (3a) Build "myprog" via "go build", or
    (3b) Install "myprog" via "go install"

    In either case, (3a) or (3b), will the modifications in step (2) be
    reflected in the built binary?
    Yes.

    Q1-variation:
    If in step (1) we installed only some of the packages in /gp1, but not all
    that are needed by "myprog", then:
    I am going to assume for the sake of this question that you mean that they
    were downloaded but not compiled. Only `go get` will ever reach out to the
    internet to fetch a package and its dependencies (which will always be
    installed in the first element in the gopath)

    (i) If we used (3a), true or false: The installed packages in /gp1 will be
    used, the others will be built (for the sake of "myprog") but not installed.
    They will be built if necessary.

    (ii) If we used (3b), true or false: The installed packages in /gp1 will
    be used, the others will be built but not installed. (Same as above.)
    They will be built if necessary.

    Q2:
    Is it OK, to have packages in /gp1 and /gp2 that share some (but not all)
    of their package paths, e.g.
    "lib/pkg1" in /gp1, and
    "lib/pkg2" in /gp2
    Of this I am unsure, but I believe that GOPATHs can share prefixes, but not
    GOPATH and GOROOT, presumably to prevent unexpectedly overriding stdlib
    packages.

    Q3:
    And just to confirm:
    If within any gopath (/gp1 or /gp2) a package directory is a symbolic link
    to an external directory, then
    dependency tracking is unpredictable.
    I think symlinks would work, though I have no evidence either way.

    Thanks
    Petar

    --

    --
  • Kyle Lemons at Nov 12, 2012 at 5:57 pm

    On Mon, Nov 12, 2012 at 9:49 AM, Kyle Lemons wrote:

    Did you try it out?
    On Sat, Nov 10, 2012 at 7:05 AM, Petar Maymounkov wrote:

    A few questions regarding the interaction between multiple GOPATHs and
    dependency tracking:

    Say I have two GOPATHs: GOPATH=/gp1:/gp2
    For all questions below, I will be building or installing a binary
    location in /gp2, whose package path is "myprog";
    "myprog" will depend on other packages found both in /gp1 and /gp2.

    Questions:

    Q1:
    Consider the steps:
    (1) In /gp1, install all packages, via e.g. "go install ..."
    (2) Modify the source of some package in /gp1
    (3) Go to /gp2, and
    (3a) Build "myprog" via "go build", or
    (3b) Install "myprog" via "go install"

    In either case, (3a) or (3b), will the modifications in step (2) be
    reflected in the built binary?
    Yes.

    Q1-variation:
    If in step (1) we installed only some of the packages in /gp1, but not
    all that are needed by "myprog", then:
    I am going to assume for the sake of this question that you mean that they
    were downloaded but not compiled. Only `go get` will ever reach out to the
    internet to fetch a package and its dependencies (which will always be
    installed in the first element in the gopath)

    (i) If we used (3a), true or false: The installed packages in /gp1 will
    be used, the others will be built (for the sake of "myprog") but not
    installed.
    They will be built if necessary.

    (ii) If we used (3b), true or false: The installed packages in /gp1 will
    be used, the others will be built but not installed. (Same as above.)
    They will be built if necessary.
    Oops, my fingers got away from me. They will be built and installed in the
    corresponding gopath directories if necessary, because you asked it to "go
    install" which applies to all dependencies as well as the target.

    Q2:
    Is it OK, to have packages in /gp1 and /gp2 that share some (but not all)
    of their package paths, e.g.
    "lib/pkg1" in /gp1, and
    "lib/pkg2" in /gp2
    Of this I am unsure, but I believe that GOPATHs can share prefixes, but
    not GOPATH and GOROOT, presumably to prevent unexpectedly overriding stdlib
    packages.

    Q3:
    And just to confirm:
    If within any gopath (/gp1 or /gp2) a package directory is a symbolic
    link to an external directory, then
    dependency tracking is unpredictable.
    I think symlinks would work, though I have no evidence either way.

    Thanks
    Petar

    --

    --
  • Petar Maymounkov at Nov 12, 2012 at 8:48 pm
    Inline:
    On 12 November 2012 12:51, Kyle Lemons wrote:
    On Mon, Nov 12, 2012 at 9:49 AM, Kyle Lemons wrote:

    Did you try it out?
    Yes. I tried everything once with symbolic links and once without.
    And I am fairly certain that all dependency checking falls apart
    when you have multiple gopaths and symbolic links.

    Without the symbolic links, things seem to work as expected in
    the questions below.
    On Sat, Nov 10, 2012 at 7:05 AM, Petar Maymounkov <petarm@gmail.com>
    wrote:
    A few questions regarding the interaction between multiple GOPATHs and
    dependency tracking:

    Say I have two GOPATHs: GOPATH=/gp1:/gp2
    For all questions below, I will be building or installing a binary
    location in /gp2, whose package path is "myprog";
    "myprog" will depend on other packages found both in /gp1 and /gp2.

    Questions:

    Q1:
    Consider the steps:
    (1) In /gp1, install all packages, via e.g. "go install ..."
    (2) Modify the source of some package in /gp1
    (3) Go to /gp2, and
    (3a) Build "myprog" via "go build", or
    (3b) Install "myprog" via "go install"

    In either case, (3a) or (3b), will the modifications in step (2) be
    reflected in the built binary? Yes.
    Q1-variation:
    If in step (1) we installed only some of the packages in /gp1, but not
    all that are needed by "myprog", then:
    I am going to assume for the sake of this question that you mean that they
    were downloaded but not compiled. Only `go get` will ever reach out to the
    internet to fetch a package and its dependencies (which will always be
    installed in the first element in the gopath)
    I am not referring to get/install from the internet here at all.
    By "installed" I mean that some packages were built with
    "go install" so that the comiled libraries are actually stored (as opposed
    to "go build" when they are not).
    (i) If we used (3a), true or false: The installed packages in /gp1 will
    be used, the others will be built (for the sake of "myprog") but not
    installed.
    They will be built if necessary.
    (ii) If we used (3b), true or false: The installed packages in /gp1 will
    be used, the others will be built but not installed. (Same as above.)
    They will be built if necessary.
    Oops, my fingers got away from me. They will be built and installed in the
    corresponding gopath directories if necessary, because you asked it to "go
    install" which applies to all dependencies as well as the target.
    Makes sense.
    Q2:
    Is it OK, to have packages in /gp1 and /gp2 that share some (but not all)
    of their package paths, e.g.
    "lib/pkg1" in /gp1, and
    "lib/pkg2" in /gp2
    Of this I am unsure, but I believe that GOPATHs can share prefixes, but
    not GOPATH and GOROOT, presumably to prevent unexpectedly overriding stdlib
    packages.
    Q3:
    And just to confirm:
    If within any gopath (/gp1 or /gp2) a package directory is a symbolic
    link to an external directory, then
    dependency tracking is unpredictable.
    I think symlinks would work, though I have no evidence either way.
    I am not sure this is true.

    Thanks
    P

    Thanks
    Petar

    --
    --
  • Russ Cox at Nov 25, 2012 at 7:27 pm

    Q1:
    Consider the steps:
    (1) In /gp1, install all packages, via e.g. "go install ..."
    (2) Modify the source of some package in /gp1
    (3) Go to /gp2, and
    (3a) Build "myprog" via "go build", or
    (3b) Install "myprog" via "go install"

    In either case, (3a) or (3b), will the modifications in step (2) be
    reflected in the built binary?
    No. Different GOPATH roots and the GOROOT itself are all treated as
    separate worlds, although links are allowed between them. The
    assumption is that if you are working in world #2 then the other
    worlds are - if installed binaries exist - up to date and you only
    care about rebuilding things in world #2.
    Q1-variation:
    If in step (1) we installed only some of the packages in /gp1, but not all
    that are needed by "myprog", then:
    (i) If we used (3a), true or false: The installed packages in /gp1 will be
    used, the others will be built (for the sake of "myprog") but not installed.
    (ii) If we used (3b), true or false: The installed packages in /gp1 will be
    used, the others will be built but not installed. (Same as above.)
    If you use go build, the missing packages will be built but not installed.
    If you use go install, they will be installed too.
    Q2:
    Is it OK, to have packages in /gp1 and /gp2 that share some (but not all) of
    their package paths, e.g.
    "lib/pkg1" in /gp1, and
    "lib/pkg2" in /gp2
    Yes.

    For the most part, there are no assumptions made about higher-level
    structure. Each import path is looked up separately. The only time
    when import paths are interpreted for structure is during 'go get', to
    map an import path to its enclosing source code repository path. If
    the paths in the question were, say, github.com/petar/lib/x1 and
    github.com/petar/lib/x2, then while that's fine for building code, go
    get -u will probably only update the first github.com/petar/lib it
    finds.
    Q3:
    And just to confirm:
    If within any gopath (/gp1 or /gp2) a package directory is a symbolic link
    to an external directory, then
    dependency tracking is unpredictable.
    Yes. There is no attempt to make sense of symlinks; you add them at
    your own risk. Things might work now that won't work later, or vice
    versa.

    Russ

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 10, '12 at 3:05p
activeNov 25, '12 at 7:27p
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase