x/playground: support third-party imports #31944
Comments
|
e.g. @neild posted this snippet recently: https://play.golang.org/p/1rR97pPojOd ... it'd be nice if that actually worked. |
|
Well, that was easy... bradfitz@go:~/src/golang.org/x/playground$ git di
diff --git a/sandbox.go b/sandbox.go
index 7493213..bf7a421 100644
--- a/sandbox.go
+++ b/sandbox.go
@@ -325,7 +325,7 @@ func compileAndRun(req *request) (*response, error) {
exe := filepath.Join(tmpDir, "a.out")
goCache := filepath.Join(tmpDir, "gocache")
cmd := exec.Command("go", "build", "-o", exe, in)
- cmd.Env = []string{"GOOS=nacl", "GOARCH=amd64p32", "GOPATH=" + os.Getenv("GOPATH"), "GOCACHE=" + goCache}
+ cmd.Env = []string{"GOOS=nacl", "GOARCH=amd64p32", "GO111MODULE=on", "GOPROXY=https://proxy.golang.org", "GOPATH=" + os.Getenv("GOPATH"), "GOCACHE=" + goCache}
if out, err := cmd.CombinedOutput(); err != nil {
if _, ok := err.(*exec.ExitError); ok {
// Return compile errors to the user.There's a minor complication with supporting the legacy |
|
Agreed this would be nice, and is easier now than before. There are no additional security concerns with this feature request. It's always been possible to accomplish this in a round-about way: by re-writing the snippet such that all third-party imports are inlined into the main program (similar to what bundle does). If the snippet does too much and takes too long to run, it'll still time out, etc.
txtar format comes to mind. One can also imagine a more featureful UI that allows adding extra files. For example, https://gist.github.com/ has an "Add file" button that adds another text box. Maybe we can just have the playground run gists. *flashbacks to 2016* 😱 There's also some overlap with https://github.com/dave/jsgo#how-it-works and perhaps some other playground-like projects (https://goplay.space/, etc.).
As long as we fix #31889, using |
|
One easy way to support non- import (
"fmt"
"gopkg.in/errgo.v2/errors" // v2.1.0+incompatible
)But that doesn't describe all of the transitive dependencies, and thus isn't particularly reproducible. |
|
@bcmills, or how about this: if the user hits "play" or "share" on a package that uses a third-party import, we append the auto-generated go.mod to the end of the textarea buffer (using whatever magic delimiter syntax we come up with), so it's included in shares and reproducible. e.g. user writes: package main
import "github.com/davecgh/go-spew/spew"
func main() {
spew.Dump(map[string]string{"foo": "bar"})
}Then hits "Run" or "Share" and we first change it to: |
|
I love the idea. And it really comes to this: support multiple files in playground. I like the idea of using delimeters per file (txtar). I really wanted to implement support for multiple files, but I hate the idea of adding a box per each file - it does not feel right for the current UI - I tried multiple options there. I support the idea of having multiple files specified by txtar, also main.go does not have to be prefixed by any file marker. |
|
Change https://golang.org/cl/176317 mentions this issue: |
|
The basic functionality (without any of the txtar etc multi-file splitting) is now done in CL 176317. It's off by default for now with an env flag (ALLOW_PLAY_MODULE_DOWNLOADS) set to false in the Dockerfile. That gives us a quick knob to turn it off later. We also want to do some cleaning probably, so the disk doesn't fill. We'll probably want to hold a RWMutex while cleaning to avoid #31948 |
|
Actually, CL 176317 now also cleans up after itself (any downloaded modules) after each build. |
|
I would still rather we use a separate textarea instead of tacking the files together in the same buffer. I find it really useful to be able to press ⌃a ⌃c and paste the result directly into |
|
@bcmills, we can start with a single buffer because it's a ton easier. We can add UI later, once somebody has time for that.
a) maybe playground snippets should only be snippets :) |
|
Yes, please lets start with a single txtar buffer. We can worry about fancier UI later. |
|
A discussion around whether to support multiple files in the playground is in issue #3806. |
|
Would this be only for pure Go imports or would it also work for self contained cgo using packages? |
|
Pure Go. It's still nacl for now. (See #30439 for removing nacl and moving the playground to a different type of sandbox, which might then support cgo) |
Also, modernize the Dockerfile while I'm at it, using multi-stage builds more aggressively, and stop using gitlock (golang/go#26872) and switch to using Go modules to build the playground. (This also turns the playground into a module.) Updates golang/go#31944 Change-Id: Ic6f6152469f1930fd04180a3d1e63ed92ea2cfbd Reviewed-on: https://go-review.googlesource.com/c/playground/+/176317 Reviewed-by: Yury Smolsky <yury@smolsky.by>
andybons
added
the
NeedsInvestigation
|
Change https://golang.org/cl/176940 mentions this issue: |
Updates golang/go#31944 Change-Id: Iffc0755cca419b72d8facd8ece950e78cdae892e Reviewed-on: https://go-review.googlesource.com/c/playground/+/176940 Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
This is amazing because it lets library authors add playground links to document their API. |
|
@akyoto even better, examples in godoc could in principle automatically link to the playground. |
|
Thanks so much for doing this! Here's one issue: I just tried a snippet I was sharing yesterday and I get an error from vet, although the actual code works as expected: The code is at: https://play.golang.org/p/cy1YkpSRtZJ |
|
@ysmolsky Yes. When I hard-reloaded, the issue went away. Thanks! |
|
Yeah, vet+modules required an update to the protocol and new JS client code. |
Updates golang/go#32040 Updates golang/go#31944 (Notably, you can now include a go.mod file) Change-Id: I56846e86d3d98fdf4cac388b5b284dbc187e3b36 Reviewed-on: https://go-review.googlesource.com/c/playground/+/177043 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
Change https://golang.org/cl/177421 mentions this issue: |
Previously, handleFmt applied gofmt/goimports formatting to .go files only. This change makes it apply formatting to go.mod files as well. The cmd/go/internal/modfile package (well, a non-internal copy thereof) is used to perform the go.mod file formatting. Add test cases for error messages, and fix some cases where the paths weren't accurate. Detect when the error was returned by format.Source and needs to be prefixed by using the fixImports variable instead of checking for the presence of the prefix. This makes the code simpler and more readable. Replace old fs.m[f] usage with fs.Data(f) in fmt.go and txtar_test.go. Updates golang/go#32040 Updates golang/go#31944 Change-Id: Iefef7337f962914817558bcf0c622a952160ac44 Reviewed-on: https://go-review.googlesource.com/c/playground/+/177421 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
Running https://play.golang.org/p/-LQxD_2TQWw results in the output: Changing the code somewhat (by for example adding a new empty line) and running it does not output the error from go vet. (This is probably the same issue that @rogpeppe was seeing) |
|
@peterhellberg, deploying a fix now: https://go-review.googlesource.com/c/playground/+/177617 |
|
The import doesn't use the latest package in github.com. Cannot specify the import package version. |
|
@toby1991 The playground caches builds, does it pull the new version of the package you are importing if you change the code in the playground? |
Yeah, I realized that. And I've also change the code, it will rebuild. But the package is still not the latest. So I think the package fetching service also has caches? And the caches of the package fetching service is based on package name which is without the package version? |
Note that you can add a go.mod file on the playground, which then enables you to specify versions (for example using a tag or commit hash). The syntax looks like this: Here is a complete example: |
|
@thepudds Thank you very much! It works like a charm!! |
|
Hi everyone, can someone help me with this problem? https://play.golang.org/p/BuJWq6L4Mx2 I got the following errors after clicking 'Run': I added the block below because I want to force Go Playground to use my latest package version as previous package got some problems: |
|
That package doesn't support GOOS=nacl GOARCH=amd64p32 (which the playground uses for now): You can reproduce locally with: |
|
Hi, looks like I've got an issue with playground - it does not use the latest available version of 3rd party import. In my particular case I try to use It's clearly visible as I got a particular case that still works in 3.5.1, but errors on 3.6.1 - see https://play.golang.org/p/wXQhQlvs30V semver lib entry on https://index.golang.org/index is while I use the newest revision (still using |
|
@lootek It seems to be an issue with installing the latest tagged version: Installing version v3.5.1Installing version v3.6.1Conclusionv.3.5.1 is the last tagged version that doesn’t include a |
|
oh, ok. I'll open an issue there then, thanks a lot! (btw my case is a known bug on blang/semver: blang/semver#55 ) |
Don't share a cache namespace between clients wanting vet (new) and not wanting vet (old). This was causing issues like: golang/go#31944 (comment) And unrelated: a README deploy fix, broken from my earlier Makefile cleanup. Change-Id: Ibed7f91c739ac65e33ee8d73eed066a7a81f938c Reviewed-on: https://go-review.googlesource.com/c/playground/+/177617 Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
edit: I've changed the import path of the package to It looks like there is a bug: third-party imports sometimes work, and sometimes do not. For example, https://play.golang.org/p/8hE61BnO8oB usually, but not always, fails with: But https://play.golang.org/p/YrPAekuiiP4, which uses the same third-party package, appears to work: |
See #8 and golang/go#31944 (comment) for the background.
|
Yeah, I think this is all done now! |
It's time for the playground to support importing third-party packages.
We have https://proxy.golang.org/ now which is the hard piece.
It might have to assume
@latestfor now, unless we let people write a go.mod file somehow (magic comments either one per module version, or magic comments separating the textarea into N logical files, ala mime/multipart by easier to type?)/cc @bcmills @dmitshur @ysmolsky
The text was updated successfully, but these errors were encountered: