FAQ
I'm hoping I misunderstand this. So, please correct me if so. Let me give
an example I think is important, and should be considered important in the
design of Go.

Suppose i have a hypothetical project constant_time_sorting which has 3
packages, the main constant_time_sorting along with subpackages
magic_algorithm and utilities organized like so:
constant_time_sorting/
magic_algorithm/
utilities/

And, i host this project on github at
github.com/rliebling/constant_time_sorting

If i understand correctly, to import my subpackages (magic_algorithm and
utilities) i will not be able to use a local import (since my project is
hosted on github.com, obtained via go get
github.com/rliebling/constant_time_sorting, it is not a local project).
So, i have to specify the full import path for magic_algorithm and
utilities.

Now, if someone else were to fork my project (say to fix a bug), they will
have to change the import paths before being able to build their copy of
this project (since it is also a remote project). They fix the bug and
kindly submit a pull request to me to incorporate into what will quickly
become a popular Go project. However, someone has to play some games with
the pull request (either the submitter or the receiver) since the changes
they had to make included changing import paths.

This seems like a serious impediment to a common github workflow. And,
it's not really unique to github either. the point is that one cannot just
fork a project and have it build without first making changes. And, that
seems like a bad call. Admittedly, i don't understand what it would take
to implement a solution that allows local (relative) imports within a
remote project but it seems like a very important feature and I would
encourage the team to make it happen. I have not done much go programming,
but it's already negatively impacted me several times.

best
rich

On Sunday, March 11, 2012 12:53:47 PM UTC-7, rsc wrote:

*** Submitted as fc524d42fb8c ***

cmd/go: local import fixes

1) The -D argument should always be a pseudo-import path,
like _/Users/rsc/foo/bar, never a standard import path,
because we want local imports to always resolve to pseudo-paths.

2) Disallow local imports in non-local packages. Otherwise
everything works but you get two copies of a package
(the real one and the "local" one) in your binary.

R=golang-dev, bradfitz, yiyu.jgl
CC=golang-dev
http://codereview.appspot.com/5787055


http://codereview.appspot.com/5787055/

Search Discussions

  • Andrey mirtchovski at Oct 1, 2012 at 11:28 pm

    Now, if someone else were to fork my project (say to fix a bug), they will
    have to change the import paths before being able to build their copy of
    this project (since it is also a remote project). They fix the bug and
    kindly submit a pull request to me to incorporate into what will quickly
    become a popular Go project. However, someone has to play some games with
    the pull request (either the submitter or the receiver) since the changes
    they had to make included changing import paths.
    there is a trick to this which most go programmers working with github
    are aware of, say that i forked your github repo, my fork will be
    called 'github.com/mirtchovski/constant_time_sorting. to work with it
    without having to change any import paths i would:

    $ cd $GOROOT/src/github.com/rliebling/
    $ rm -rf constant_time_sorting
    $ git clone github.com/mirtchovski/constant_time_sorting

    that replaces your repository with my fork but doesn't change any import paths.
  • Dave Cheney at Oct 1, 2012 at 11:30 pm

    $ cd $GOROOT/src/github.com/rliebling/
    $ rm -rf constant_time_sorting
    $ git clone github.com/mirtchovski/constant_time_sorting

    that replaces your repository with my fork but doesn't change any import paths.
    Or even easier

    cd $PKG
    git checkout master #don't blame me for this git facepalm
    vim vim vim
    git commit
    git push $YOURFORK
  • Rliebling at Oct 2, 2012 at 4:33 pm
    Thanks everyone for the suggestions of how to cope with this problem.
    However, while these approaches help an individual cope, they are, in my
    view, not well suited to team development where the team cannot wait for
    the patch to be accepted.

    They will instead import their own fork of the 3rd party library until that
    time. Meanwhile, they will have to have one version to submit a patch, as
    described in the several responses to my original question, and another
    version to actually reference in their code. Consider also the case where
    a hierarchy of repos is used for a project, with different gatekeepers at
    the different levels (eg used by linux, but presumably used in other
    projects, as well.) In this case, again, one cannot simply accept standard
    patches from the lower repos because import statements will need to be
    changed to move the code from one repo to another.

    Russ stated earlier:
    Source files are significantly less portable if you are using relative
    imports,
    because now you can't resolve anything without knowing where the file
    came from.
    My contention is this addresses the wrong problem. First, the standard
    unit of reuse should be the package, not the source file. Source files in
    Go are already hard to reuse just by copying to another package, as the
    file likely depends on other files in the same package without any explicit
    reference to those files. But, more importantly, i think the github
    approach to code reuse is significantly more common and more important. In
    this approach one uses some open source library (eg using rubygems/bundler
    in ruby), specifying some version constraint, btw. When the need arises to
    make your own changes/fixes/enhancements to that, you fork it, and use your
    own fork up until your changes have been accepted by the original
    maintainer (if ever). This approach has led to flourishing development
    communities with constantly improving libraries. Encouraging instead a
    system where developers merely appropriate individual source files for
    their own use runs counter to this approach.

    But, maybe the point of all this is that we should just not use "go get" or
    "go install" because the package management aspects leads to these
    difficulties. I see two paths:
    1. never use 'remote imports': treat all packages as local so this
    requirement vanishes. Someone writes a package management tool for Go that
    behaves this way and life gets better.
    2. Separate the notion of the source repo for the code from the directory
    and import naming scheme. Esssentially this is how java works, where
    packages might be named com.facebook.api.something, but the source code for
    it might come from your local fork of the project or someone else's.
    Again, someone needs to write a tool to make this easy to get code and
    build it. (Please don't make everything xml, like java/maven/ant.)
    The bottom line seems to be that "go get" and "go install" don't cut it.

    The current situation creates annoying friction to collaboration with Go.
    The result will be less collaboration, which will be a loss for the whole
    Go community. I hope you will reconsider this issue. The answer need not
    be allowing local imports. But, something in my view needs to be done to
    eliminate the friction of forking a Go project involving multiple packages.

    best,
    rich

    On Monday, October 1, 2012 4:30:44 PM UTC-7, Dave Cheney wrote:

    $ cd $GOROOT/src/github.com/rliebling/
    $ rm -rf constant_time_sorting
    $ git clone github.com/mirtchovski/constant_time_sorting

    that replaces your repository with my fork but doesn't change any import
    paths.

    Or even easier

    cd $PKG
    git checkout master #don't blame me for this git facepalm
    vim vim vim
    git commit
    git push $YOURFORK
  • Andrey mirtchovski at Oct 1, 2012 at 11:57 pm

    $ cd $GOROOT/src/github.com/rliebling/
    $ rm -rf constant_time_sorting
    $ git clone github.com/mirtchovski/constant_time_sorting
    that's GOPATH, of course.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedOct 1, '12 at 11:24p
activeOct 2, '12 at 4:33p
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase