I'm learning the Go language by following a tutorial. Not wanting to just blindly copying the examples, but understanding what's going on, I came accross the following puzzling case:
In the tutorial the import statement was written as:
import (
"fmt"
"example.com/greetings"
)
I first was surprised about the empty line between the two strings and thought that this is just following some style guide, and when creating my program, I wrote it simply as
import (
"fmt"
"example.com/greetings"
)
To my astonishment, when saving the code (I was using Visual Studio Code for editing at that time), the editor re-inserted the empty line, so I reckon that there must be a deeper reason for it.
I can't see any effect on my program, because when I later removed the line with a less presumptuous editor (nano), my program seemed to run the same as with empty line included ... but maybe I just missed something. So, my question, does this empty line have a deeper meaning, which I just don't grasp yet?
There is no significance to the empty lines in the import group.
Some editors (including VSCode) put standard library imports first, then add an empty line, and then other (3rd party imports). Also the 2 groups are sorted alphabetically.
Again, there is no significance to this other than being easier to read. It also comes handy if everyone formats imports like this, so there are no "meaningless" commits in a version system due to different import sorting / organizing.
Related
I found that very useful Go library in the web https://github.com/deckarep/golang-set that tries to port Python sets to Go.
Thanks to Visual Studio Code I eventually got it to work by importing the library import "github.com/deckarep/golang-set" and calling a function in my code:
mySet := mapset.NewSet()
VS Code automatically recognizes the alias and replaces the import directive:
import mapset "github.com/deckarep/golang-set"
However, being someone who finds those aliases confusing, I was trying to remove it but doing so, VSCode removes it from both the import statements and my code. VS Code then tells me:
undeclared name: NewSet compiler(UndeclaredName)
The package name from NewSet(...) is also package mapset. So I thought I could simply remove it. But it does not work.
I also tried to work analogously to other 3rd party packages and call the functions by the repository's name:
mySet := golang-set.NewSet()
This also leads to an error. Is the removing of the alias not possible here due to the hyphen maybe or am I overseeing something else?
Several things here:
mapset is the package name. You can see this by looking at the package source code.
While the import alias, in this case, is not strictly needed from a language standpoint, it's added for clarity, since the package name (mapset) does not match the import path (golang-set). Without the alias in the import statement, there's no way to tell how the package is referenced. This is why it's important for it to be there.
You cannot use golang-set as your import name, becuase the - character is not permitted in an import alias. However, if you really want to, you could use golang_set or similar, by explicitly providing this as your alias:
import golang_set "github.com/deckarep/golang-set"
Note that this goes against naming conventions, in that packages should not have _ characters in the name. But it should still be valid.
Best practice would be just to use mapset as the alias. It's the least confusing of all the available options (which is why it's automatically selected).
Several organizations distribute variants of the same project, and we regularly pull changes from one another. It would be great if we could eventually merge code repositories and maybe, maybe have a common source tree managed by a consortium. However, each member would probably want the option of distributing their own variant without too much pain for customers in case there is trouble upstreaming changes required to work with newer products.
The project consists of three packages:
A library
A compiler executable that outputs go code that needs to import the library
A utility executable that uses code generated by #2 and links with #1
A big annoyance, when pulling changes back and forth, is gratuitous differences in import paths. We basically have to edit every version of import "github.com/companyA/whatever" to import "companyB.com/whatever". Of course these problems would go away with (gasp) relative import paths. If we resorted to such heresy, our compiler can just hard-code the absolute import path in generated code to isolate end users from the library's import path. It would also require only one gratuitous difference in the source trees (the line in the compiler that outputs import statements) rather than a bunch.
But anyway, I know relative import paths are bad - this is a tricky situation. I know this is similar to questions such as this or this, because the answer of just asking end users to create a directory called companyB.com and cloning something from companyA in there is just not going to fly for practical and political reasons.
I already know that go is not really good at accommodating this scenario, so I'm also not asking for a magic bullet to make go handle something it can't. Another thing that unfortunately won't fly is asking customers to curl whatever | sh, as this is viewed as too much of a liability (deemed "training customers to do dangerous things"). Maybe we could forego go get and have everyone clone to some neutral non-DNS-name under $GOPATH/src, but we would need to do this without a "flag day" in which code suddenly breaks if it's in the wrong place.
My question is whether anyone has successfully merged SDK-type projects with existing end users, and if so, how did you do it, what worked, and what didn't? Did you in fact avoid relative import paths or gnarly GOPATH hacking, and if so was it worth it? What mechanisms did you employ (environment variables, configuration files, .project-config files in the current working directory, abusing the vendor directory, code-generation packages that figure out their absolute import path at compliation time) to make this work smoothly? Did you just muddle through with a huge amount of sed or maybe gofmt -r? Are there tricks involving clever use of .gitattributes or go generate to rewrite import paths on checkout/checkin?
Merging them is pretty easy - cross-merge so that they all match, pick one (or create a new one) as the canonical source of truth, then migrate all references to the canonical import and make all future updates there.
The probablem arises here:
each member would probably want the option of distributing their own variant without too much pain for customers in case there is trouble upstreaming changes required to work with newer products
There's no particularly good way to do that without using any of the known solutions you've already ruled out, and no way to do that depending on your threshold for "too much pain".
Without knowing more about the situation it's hard to suggest options, but if there's any way that each company can abstract their portion out into a separate library they could maintain and update at their pace while using a smaller shared library with shared responsibility, that would likely be the best option - something like the model used by Terraform for its providers? Basically you'd have shared maintenance of a shared "core" and then independent maintenance of "vendor-specific" packages.
I am trying to add some support for D programming language to my vim config. For autocompletion I need to detect packages that are included. This is not exactly hard to do in simple case:
import std.stdio;
import std.conv;
My config:
set include=^\\s*import
set includeexpr=substitute(v:fname,'\\.','/','g')
Works great.
However, imports can have more complicated format, for example:
package import std.container, std.stdio = io, std.conv;
I was not able to find a simple way to parse this with include and includeexpr.
Also there is a second problem: import can have different access modifiers, like public and private. VIM scans included files recursively, import statements from included files are parsed too. But I need to distinguish between the file I am working with now and files which are scanned automatically: in current file all imports should be detected, but in other files only public import statements should add more files to the search.
Thanks for help.
Update
It's a shame if this can not be done without full parsers. Essentially, I only need two things:
ability to return an array from includeexpr instead of one file name
ability to distinguish between includes in current and other files
I think only way to do it reliably is to use complete parser and semantic analyzer. D Completion Daemon (https://github.com/Hackerpilot/DCD/tree/master/editors/vim ) has vim plugin and is not very resource-hungry.
Vim's include mechanism and 'includeexpr' are heavily influenced by the C programming language and only work for single files. You cannot return a list of filenames, so it won't be possible to support D's complex include mechanism with Vim. Use an IDE that is fully tailored to support the programming language, not a general-purpose text editor.
By default, Go treats unused import as error, forcing you to delete the import.
I want to know if there exists some hope to change to this behavior, e.g. reducing it to warning.
I find this problem extremely annoying, preventing me from enjoying coding in Go.
For example, I was testing some code, disabling a segment/function. Some functions from a lib is no longer used (e.g. fmt, errors, whatever), but I will need to re-enable the function after a little testing. Now the program won't compile unless I remove those imports, and a few minutes later I need to re-import the lib.
I was doing this process again and again when developing a GAE program.
Adding an underscore (_) before a package name will ignore the unused import error.
Here is an example of how you could use it:
import (
"log"
"database/sql"
_ "github.com/go-sql-driver/mysql"
)
To import a package solely for its side-effects (initialization), use
the blank identifier as explicit package name.
View more at https://golang.org/ref/spec#Import_declarations
The var _ = fmt.Printf trick is helpful here.
I have the same problem. I understand the reasoning for why they implemented the language to disallow unused imports and variables, but I personally find this feature annoying when writing my code. To get around this, I changed around my compiler to allow optional flags for allowing unused variables and imports in my code.
If you are interested, you can see this at https://github.com/dtnewman/modified_golang_compiler.
Now, I can simply run code with a command such as go run -gcflags '-unused_pkgs' test.go and it will not throw these "unused import" errors. If I leave out these flags, then it returns to the default of not allowing unused imports.
Doing this only required a few simple changes. Go purists will probably not be happy with these changes since there is good reason to not allow unused variables/imports, but I personally agree with you that this issue makes it much less enjoyable to code in Go which is why I made these changes to my compiler.
Use goimports. It's basically a fork of gofmt, written by Brad Fitzpatrick and now included in the go tools packages. You can configure your editor to run it whenever you save a file. You'll never have to worry about this problem again.
Use if false { ... } to comment out some code. The code inside the braces must be syntactically correct, but can be nonsense code otherwise.
If you are using the fmt package for general printing to console while you develop and test then you may find a better solution in the log package.
A lot of people have already commented with valid justification and I also acknowledge the original author's intention. However, Rob Pike mentioned in different forums that Go is the outcome of simplification of the processes that a few other mainstream programming languages either lack or not easy to achieve. It's Go's language semantics as well as to make the compilation faster, there are a lot of things that are adopted which initially seems inefficient.
To make it short, unused imports are considered as errors in Go as it blots the program and slows down the compilation. Using import for side effect (_) is a workaround, however, I find this confusing at times when there is a mix of valid imports with side effects along with side effects imported purely for the purpose of debugging/testing especially when the code base is large and there is a chance to forget and not delete unintentionally which may confuse other engineers/reviewers later. I used to comment out the unused ones, however, popular IDEs such as VS code and Goland can use goimports easily which does the insertion and deletion of the imports pretty well. Please refer to the link for more info, https://golang.org/doc/effective_go.html#blank_import
put this on top of your document and forget about unused imports:
import (
"bufio"
"fmt"
"os"
"path/filepath"
)
var _, _, _, _ = fmt.Println, bufio.NewReader, os.Open, filepath.IsAbs
The reference page (use "toggle all") for Processing.js says the import command remains unimplemented. It references a page for the Java Processing language that describes a usage pattern like this: import processing.opengl.*;
I see at Github that some work on the import command was committed to the root in May. Does anyone know how this syntax works in a JavaScript environment? It's not clear what the path to the library file and its assets would be. Does this depend on the use of an environment variable similar to PYTHONPATH, or is there a directory naming convention?
Finally, would you care to discuss the relative merits of the import command (assuming it now works) versus the approach described here, and discussed briefly here on StackOverflow.
I was looking for a similar solution. Perusing the processing.js base code, I noticed that you can simply list multiple files in your datasrc declaration if you separate the file names with spaces. That kind of does what I want, although the result is multiple ajax calls to load the separate scripts.
<canvas id="test" datasrc="resources/pjs/Spot.class.pjs resources/pjs/cursor.pjs"></canvas>
I think a cleaner solution, given the current state of the processing.js code (as of July 2010) would be to simply build a server-side code concatenator a-la minify:
http://groups.google.com/group/minify