[RFC] Unify the running of Go applications

[dlsniper]

Hi,

After seeing yet another problem with running various type of apps (#2012 (comment)), I've started thinking that maybe the runners can be unified.

I'm thinking of having a single run configuration called Go or Go Application which has the following options for the run kind:

• single file -> lets you select a single file -> translates into go build path/to/file.go
• directory -> lets you select a directory -> translates into cd path/to/directory && go build .
• package -> lets you select a package -> translates into cd $GOPATH/src/package/name && go build package/name

This way we don't use go run anymore and people are not confused on which run type to use and the plugin has less code to maintain.

What do you think?

[zolotov]

What do you think?

Just no. go run != go build path/to/file.go and run directory is not cd path/to/directory && go build .

go run is still needed for running single files. Also it's needed for scratches

[dlsniper]

go run != go build path/to/file.go

go run is just a shortcut to go build -o /tmp/file file.go && /tmp/file && rm -f /tmp/file

run directory is not cd path/to/directory && go build .

Technically that works and it also solves the problem of having multiple files in the main package. The alternative would be to use go build file1.go file2.go ... so I guess that could be used as well (if the files are added automatically by the plugin).

[zolotov]

Well, ok. Maybe it makes sense

[kolkov]

+1 а Good idea)
First time when I using plugin, I spent one hour to setup run configuration for multifiles project. Only Google helped me.
Is it possible to make the plugin itself detecting my configuration?

[fabian-z]

As a relatively new user of the plugin, I am very much in favor of this idea.

Currently, I resort to setting a run configuration for a "Go application" with a run kind of "File" and a value of "./". That produces a warning about incorrect configuration, but will run go build -o $projectDir/Main ./ and execute the resulting binary upon choosing "Continue anyway".

As I come from a terminal workflow I'm used to the free structure and underlying workings of go build - it would be nice to have the whole flexibility in this plugin, without having to resort to inconvenient workarounds.

Regarding the go run / go build issue, there is a blog post from one of the Go authors Dave Cheney: Using go test, build and install

[zolotov]

@fabian-z and what's your suggestion? I didn't get it.

Regarding the go run / go build issue, there is a blog post from one of the Go authors Dave Cheney: Using go test, build and install

According to this blog post you also can select package kind running and set package to build.

[fabian-z]

@zolotov
Sorry If I have not made my point clear.
If I try to use the package run kind with value "main", I get the same error as mentioned here: #2012 (comment)

In the terminal, I usually do go build && ./$packageDir. It will be nice to have this possibility in the plugin without resorting to the workaround I outlined above. To cite @margerum:

I'm effectively doing a multi file build using package main.

Because of this and the reasons given earlier, I support the suggestions made by @dlsniper.

[zolotov]

If I try to use the package run kind with value "main", I get the same error as mentioned here: #2012 (comment)
without resorting to the workaround I outlined above.

It's not a workaround, it's the proper building approach described in blogpost that you've mentioned (http://dave.cheney.net/2014/01/21/using-go-test-build-and-install) and in go build documentation (https://golang.org/cmd/go/#hdr-Compile_packages_and_dependencies).

Build compiles the packages named by the import paths, along with their dependencies, but it does not install the results.

Suggestion made by @dlsniper is mainly about getting rid of go single file run configuration. Implementing directory-kind run configuration is not on my plan because it is too ambiguous way to build.

As for relative paths, imaging you set ./myPackage as a directory to build. What is the full path to directory? How IDE can decide what is the directory it should use as root to resolve relative path?

[fabian-z]

It's not a workaround,

The only way I found to run my application with the plugin is to confirm an error message stating the run configuration is still wrong and If I want to continue anyway. This is definitely not an ideal workflow, I would most certainly call my current way of running a workaround.

Suggestion made by @dlsniper is mainly about getting rid of go single file run configuration. Implementing directory-kind run configuration is not on my plan because it is to ambiguous way to build.

Maybe I misunderstood the OP then. I read that he suggests:

directory -> lets you select a directory -> translates into cd path/to/directory && go build .

as a run kind for Go Applications. This is exactly what I would need and propose, too. I also see no ambiguity here. May you elaborate on that?

As for relative paths, imaging you set ./myPackage as a directory to build. What is the full path to directory. How IDE can decide what is the directory it should use as root to resolve relative path?

I don't see a big problem here: Like suggested by OP, the IDE could just cd ./myPackage && go build && ./myPackage to run the application. This is exactly the same procedure achieved by my workaround and it works for virtually all Go applications with package main I've come across yet.

[zolotov]

cd ./myPackage

Relative to what? How to calculate the whole path or "myPackage"?

[dlsniper]

The only way I found to run my application with the plugin is to confirm an error message stating the run configuration is still wrong and If I want to continue anyway. This is definitely not an ideal workflow, I would most certainly call my current way of running a workaround.

It would be helpful to detail what's your project layout, why do you need to build the directory and neither a single file nor a package won't work for you.

the IDE could just cd ./myPackage && go build && ./myPackage to run the application.

I believe that's where the confusion happens. The IDE, like @zolotov said, is not able to guess what the ./ (relative part) the example refers to. Also, aside from your project not being in a GOPATH, then you can always use the Package configuration to run the app.

Also, this issue is created to discuss the various cases people have in building Go apps and then see if the plugin can somehow improve on this and that's why the clear the context the easier it is to understand various use-cases and see how the plugin could handle those.

[fabian-z]

Relative to what? How to calculate the whole path or "myPackage"?

I think we misunderstood each other (and my example was mistakenly using your suggested path) - if you look at my screenshot, I have to provide the working directory and output directory to the run configuration even in the current situation. Using relative paths here obviously doesn't make sense and even causes configuration errors.

I think it would be easy to take the working directory and the output directory (given as absolute path) and do cd $workingDirectory && go build -o $outputDirectory/$runConfigName && $outputDirectory/$runConigName

It would be helpful to detail what's your project layout, why do you need to build the directory and neither a single file nor a package won't work for you.

I am usually doing a multi file, main package build, contained in a single directory, similar problem to #2012
Aside from that, I like to keep my development and my GOPATH separate (separating my own effort and pulled in libraries). So that may be why the package run kind with value "main" is not working for me.