On Wed, Dec 12, 2018 at 9:08 AM Robert Engels <reng...@ix.netcom.com> wrote: > > Yes, but you still need to maintain both repos or things will break. > > I am pretty sure that the correct solution is to decouple the package from > its location. And a global Go registry can tell Go get where that package can > currently be found.
I agree with decoupling package from its location. I disagree with the global registry idea. That's the same thing they did with maven repositories in Java. Package aliases, defined locally, is a much neater solution with no global authority. Each project can define package aliases with location information, and packages of the project can import those aliases. This doesn't prevent "global" package registries, but localized package information is much more manageable in my opinion. > > Then the package maintainer informs the global registry where the package is > currently located. > > The the import statement uses the logical package name. > > For compatibility reasons the initial logical name could be the current > import path. > > Seems straightforward to me. > > On Dec 12, 2018, at 10:01 AM, Sebastien Binet <bi...@cern.ch> wrote: > > > > On Wed, Dec 12, 2018 at 4:46 PM Sotirios Mantziaris <smantzia...@gmail.com> > wrote: >> >> exactly that robert. :) >> >> On Wed, Dec 12, 2018 at 5:43 PM Robert Engels <reng...@ix.netcom.com> wrote: >>> >>> I think he is pointing out the problem I’ve asked about many times that >>> using the specified import path so ‘go get’ works is a problem. If I want >>> to move my repos to another account all referencing code breaks. >>> >>> The import paths need a logical reference. >>> >>> Think Java and package names. The package name remains constant, where it >>> is located/retrieved from changes all the time (classpath) >>> >>> I am assuming I’ve always misunderstood this, but nothing that was ever >>> stated cleared it up, so I just went with, well I guess I don’t understand >>> and move along... >>> >>> On Dec 12, 2018, at 9:36 AM, Wagner Riffel <wgrrif...@gmail.com> wrote: >>> >>> Go has nothing to do with github, you can have any import path and how many >>> repos you like as long as it exists on your file system inside $GOPATH/src >>> -wgr >>> >>> On Wed, Dec 12, 2018, 10:13 AM Sotirios Mantziaris <smantzia...@gmail.com> >>> wrote: >>>> >>>> Hi, >>>> >>>> i want to move a repo from my github account to another one. Goal is to >>>> have a new import path for the new forked repository. >>>> There are 2 ways of achieving the move: >>>> >>>> Forking >>>> Transfer repository >>>> >>>> Is it possible to fork a repo and change the import path of the repository? >>>> >>>> If the transfer option is chosen we just have to change all imports in the >>>> code, which severs the ties for the originating project. >>>> >>>> Is it possible to have: >>>> >>>> both repos >>>> every repo with it's own import path >>>> code exchange between them >>>> >>>> What are the options? > > > for compatibility sake, I usually fork instead of transfering the repository. > ie: > $> go get github.com/user/pkg > $> cd $GOPATH/src/github.com/user/pkg > $> git remote add new https://github.com/new-place/pkg > $> git checkout -b new-branch > $> find . -name "*.go" -type f -exec sed -i -e > 's|github.com/user/pkg|github.com/new-place/pkg|g' {} \; > $> git add . > $> git commit -m "all: migration to github.com/new-place/pkg" > > hth, > -s > > -- > 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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
