5 ms·

This is how imports work in go. You make it look like a url, but then can choose in the mod (the module) file if it is local or to keep the url. This makes it q

This is how imports work in go. You make it look like a url, but then can choose in the mod (the module) file if it is local or to keep the url. This makes it quite clean because files have the same import url even as relative paths change, so you can move files all around and the import statements can stay the same. It also has the added advantage that there is no single module repository like in npm. So any url / GitHub repo works so no module can permanently own a name.

tsimionescu 5y ago
> This makes it quite clean because files have the same import url even as relative paths change, so you can move files all around and the import statements can stay the same. That only works if no one is using your module as a dependency. > So any url / GitHub repo works so no module can permanently own a name. Only if go mod understands the source control mechanism, and only if the HTTP server in front of that speaks the survival go mod protocol. It's a horrible system that the go team doesn't use internally.
- icholy 5y ago
  Why do you have such strong opinions on things you clearly don't use or understand?
  - tsimionescu 5y ago
    I do use and understand these things. I have fought several times with go mod and know a few of its quirks. Go mod works by cloning the remote repository you import (unless the module it is working on has a replace directive). It does this via HTTPS or Git ssh or other source control mechanisms, based on the form of the import link and your GOPROXY and GOPRIVATE environment variables and their various flags and options. For each source control mechanism, it has some specific way to decide exactly what version to sync to (such as git tags to chose a specific commit). It also depends on how you have configured your source control in your local environment, as that is what will ultimately download the code - if you want to download modules from repos that require various forms of authentication, it's up to every dev to configure credentials for each of these (or theoretically someone could mirror them to a single repo with common auth). It's still important to note that replace directives are only used when building that particular module. Say module A depends on module B. Module B has a dependency on module github.com/proj/C, but locally adds a replace directive to replace github.com/proj/C with bitbucket.com/proj/C. When running go mod in B's folder, it will download the version of C from BitBucket. But, when building module A, it will download module C from GitHub. Replace directives are just for local builds, your dependents don't look at them.

tsimionescu 5y ago

> This makes it quite clean because files have the same import url even as relative paths change, so you can move files all around and the import statements can stay the same. That only works if no one is using your module as a dependency. > So any url / GitHub repo works so no module can permanently own a name. Only if go mod understands the source control mechanism, and only if the HTTP server in front of that speaks the survival go mod protocol. It's a horrible system that the go team doesn't use internally.

icholy 5y ago
Why do you have such strong opinions on things you clearly don't use or understand?
- tsimionescu 5y ago
  I do use and understand these things. I have fought several times with go mod and know a few of its quirks. Go mod works by cloning the remote repository you import (unless the module it is working on has a replace directive). It does this via HTTPS or Git ssh or other source control mechanisms, based on the form of the import link and your GOPROXY and GOPRIVATE environment variables and their various flags and options. For each source control mechanism, it has some specific way to decide exactly what version to sync to (such as git tags to chose a specific commit). It also depends on how you have configured your source control in your local environment, as that is what will ultimately download the code - if you want to download modules from repos that require various forms of authentication, it's up to every dev to configure credentials for each of these (or theoretically someone could mirror them to a single repo with common auth). It's still important to note that replace directives are only used when building that particular module. Say module A depends on module B. Module B has a dependency on module github.com/proj/C, but locally adds a replace directive to replace github.com/proj/C with bitbucket.com/proj/C. When running go mod in B's folder, it will download the version of C from BitBucket. But, when building module A, it will download module C from GitHub. Replace directives are just for local builds, your dependents don't look at them.