doutui7955
2018-10-19 01:56
浏览 1.1k

为什么许多golang项目直接从GitHub导入?

I'm totally new to golang, and am wondering, why many golang projects write in their source code like this way:

import  "github.com/stretchr/testify/assert"

What if this testify moved to bitbucket?

Why not download testify and import testify, like other languages?

图片转代码服务由CSDN问答提供 功能建议

我对golang完全陌生,我想知道为什么许多golang项目以这种方式在其源代码中编写 :

 导入“ github.com/stretchr/testify/assert”
  
 
 

如果此 testify 移至bitbucket吗?

为什么不像其他语言一样下载testify并 import testify

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 邀请回答

3条回答 默认 最新

  • duanping3587 2018-10-19 02:07
    已采纳

    Before I answer your question, you need to understand about the way golang manages it's packages and dependencies.


    To download packages, use the go get command. Usage example:

    $ go get github.com/stretchr/testify
    

    Above command will downloads the testify package then store it locally under work space with structure following it's url (TL;DR work space path is registered as $GOPATH env variable).

    $GOPATH/src/github.com/stretchr/testify
    

    An explanation from the doc why the downloaded package name will follow it's url:

    Get downloads the packages named by the import paths, along with their dependencies.


    Now about your question:

    Why does many golang project directly import from GitHub?

    The statement import "github.com/stretchr/testify/assert" doesn't mean that the package is directly imported from github website (through http). It's imported from your local, from github.com/stretchr/testify path under $GOPATH/src. The package was downloaded and stored there before, so it can be imported into any project.

    Below is an explanation from the documentation about the import statements:

    The Go path ($GOPATH) is used to resolve import statements.

    Also take a look at some code below (taken from my local).

    $ echo $GOPATH
    /Users/novalagung/Documents/go
    
    $ go get -u github.com/stretchr/testify
    # package will be downloaded into $GOPATH/src folder using the same structure as the github url
    
    $ tree -L 1 $GOPATH/src/github.com/stretchr/testify
    /Users/novalagung/Documents/go/src/github.com/stretchr/testify
    ├── Gopkg.lock
    ├── Gopkg.toml
    ├── LICENSE
    ├── README.md
    ├── _codegen
    ├── assert
    ├── doc.go
    ├── http
    ├── mock
    ├── package_test.go
    ├── require
    ├── suite
    └── vendor
    

    So if you want to import any packages, it must be under $GOPATH/src folder.


    what if this testify moved to bitbucket?

    It has no effect on your local project, because the required package already downloaded before. However, if you want to update it, you might need to change the package path to follows it's new url, maybe like bitbucket.org/stretchr/testify/assert? depends on what the new bitbucket url looks like.

    But I don't think the owner of the testify will do that, since it'll break lot people of codes.

    点赞 打赏 评论
  • dtt2012 2018-10-19 02:10

    why not download testify and import testify, like other languages ?

    Some libraries will do this (downloading, I mean), as Go didn't have proper package management and the way around it was to use a technique called vendoring, which basically meant to clone/snapshot the code from wherever it may exist, and use that package structure in your import statements

    The downside of that approach is that you will clearly lose out on latest updates until repeating that process, and you're not always guaranteed the code you checkout is a stable release

    点赞 打赏 评论
  • douqingnao9246 2018-10-19 12:50

    The question raises a good concern regarding the design of import paths in go. As @xpare mentioned, go brings the dependencies to your local $GOPATH. But the OP's question has not been addressed fully.

    Yes, if the authors/maintainers of github.com/stretchr/testify moved the package to bitbucket, then this will cause a problem. This might not cause a problem on you machine, since you have the dependencies on your machine, but it will cause a problem to anyone who wants to contribute to the app. Not only that, but it will also cause problems to the build server if the build server has to pull the dependencies every time.

    Even though people don't move from github to bitbucket often, this proved to be still a concern. When microsoft bought github, many packages moved to other providers. There is no guarantee that any provider, github or others, will keep the same prices, the same quality of service, the same features, etc. It is inevitable that things will move.

    Not only that, but also that authors sometimes move packages to a different location within github under a different user. This happens too.

    So is that a problem? Yes, though the design of import urls in go allows to the ability to clearly specify the dependencies, the downside is that when the package moves, the code has to change. Vendoring tends to help to make the application resistant to these changes, but vendoring doesn't help if you want to update the package.

    The design of go wanted a decentralized package management. This design is immune to problems such as the break of many npm apps due to npm controversially deleting kirk package. So if people disagree with npm philosophy, that will be a big problem. But if people don't like github, they typically move to other providers and the packages will always be there (in go, that will cause change in source code). Because of this, golang does not guarantee that all package names will be unique, and hence the full import path is necessary.

    Every approach has its pro and cons. And unfortunately for go, that means that the full import path is needed.

    点赞 打赏 评论

相关推荐