cznic / internal Goto Github PK

I'm trying to use github.com/cznic/cc/v2 in a project that uses dep. Unfortunately, dep doesn't seem to spot the dependency chain: cc -> ir -> internal/buffer

I have to solve this by specifying both projects as 'required' in my Gopkg.toml:

required = ["github.com/cznic/ir", "github.com/cznic/internal/buffer"]

This causes dep to pick up v1.0.0 of internal/buffer, which is missing the definition of buffer.Bytes.

I think cutting another release would solve this.

Package named internal can't be currently imported using vgo (issue golang/go#23970). This situation at least prevents importing module github.com/cznic/lldb (and transitively github.com/cznic/ql) and also intra-dependency import of "github.com/cznic/internal/slice" in buffer/buffer.go.

Please consider "renaming" this repo (with respect to backward compatibility) or make this package "stable" by integrating it into LLDB (#3).

$ mkdir example && cd example
$ echo "module example" > go.mod
$ echo -e "package main\n\nimport _ \"github.com/cznic/ql\"\n\nfunc main () {}" > main.go
$ vgo build
... some successful imports ...
..\..\..\v\github.com\cznic\[email protected]\btree.go:16:2: use of internal package not allowed
..\..\..\v\github.com\cznic\[email protected]\memfiler.go:13:2: use of internal package not allowed
..\..\..\v\github.com\cznic\[email protected]\buffer\buffer.go:36:2: use of internal package not allowed

Hi @cznic,

When I noticed you creating this repository it reminded me of something I've been thinking of for a while. Would you reckon that none of @internal's repositories (https://github.com/internal) may be imported by 3rd parties?

Cheers /u

lldb recently gained dependency on this library but I'm not sure whether it would be a good idea to package it... Could you clarify please? Thanks.

I'm packaging this project for fedora as a dependency for some other packages (cznic-ql, syncthing, etc.). I just noticed that tests fail on fedora rawhide (go 1.8), but only on the s390 architecture (tests pass on all other architectures).

This might indicate a race condition in your code (or tests), since build VMs are usually not all equally fast (or equally performant), and the s390 builders were unusually busy today.

The exact failure message is:

+ go test -compiler gc -ldflags '' github.com/cznic/internal/buffer
ok  	github.com/cznic/internal/buffer	1.038s
+ go test -compiler gc -ldflags '' github.com/cznic/internal/file
ok  	github.com/cznic/internal/file	1.622s
+ go test -compiler gc -ldflags '' github.com/cznic/internal/slice
--- FAIL: Test (0.00s)
	nonrace_test.go:37: 1
FAIL
FAIL	github.com/cznic/internal/slice	0.385s