I am curious whether there would be any interest to support this project on Windows.

Just cause of my curiosity - I decided to build this:

$ ./bootstrap.sh Building Please...

github.com/pkg/xattr

.....golang\pkg\mod\github.com\pkg\[email protected]\xattr.go:40:10: undefined: getxattr .....golang\pkg\mod\github.com\pkg\[email protected]\xattr.go:47:10: undefined: lgetxattr .....golang\pkg\mod\github.com\pkg\[email protected]\xattr.go:54:10: undefined: fgetxattr .....golang\pkg\mod\github.com\pkg\[email protected]\xattr.go:106:12: undefined: setxattr .....golang\pkg\mod\github.com\pkg\[email protected]\xattr.go:115:12: undefined: lsetxattr .....golang\pkg\mod\github.com\pkg\[email protected]\xattr.go:123:12: undefined: fsetxattr .....golang\pkg\mod\github.com\pkg\[email protected]\xattr.go:132:12: undefined: setxattr .....golang\pkg\mod\github.com\pkg\[email protected]\xattr.go:141:12: undefined: lsetxattr .....golang\pkg\mod\github.com\pkg\[email protected]\xattr.go:149:12: undefined: fsetxattr .....golang\pkg\mod\github.com\pkg\[email protected]\xattr.go:157:12: undefined: removexattr .....golang\pkg\mod\github.com\pkg\[email protected]\xattr.go:157:12: too many errors

github.com/thought-machine/please/src/cli

src\cli\logging.go:182:23: undefined: syscall.SIGWINCH

$ go env && go version set GO111MODULE= set GOARCH=386 set GOBIN= set GOCACHE=C:\Users\clang\AppData\Local\go-build set GOENV=C:\Users\clang\AppData\Roaming\go\env set GOEXE=.exe set GOFLAGS= set GOHOSTARCH=386 set GOHOSTOS=windows set GOINSECURE= set GOMODCACHE=C:\Users\clang.golang\pkg\mod set GONOPROXY= set GONOSUMDB= set GOOS=windows set GOPATH=C:\Users\clang.golang set GOPRIVATE= set GOPROXY=https://proxy.golang.org,direct set GOROOT=C:\Users\clang\golang set GOSUMDB=sum.golang.org set GOTMPDIR= set GOTOOLDIR=C:\Users\clang\golang\pkg\tool\windows_386 set GCCGO=gccgo set GO386=sse2 set AR=ar set CC=gcc set CXX=g++ set CGO_ENABLED=1 set GOMOD=C:\Users\clang\Desktop\please\go.mod set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config set GOGCCFLAGS=-m32 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\clang\AppData\Local\Temp\go-build341091154=/tmp/go-build -gno-record-gcc-switches go version go1.15 windows/386

First thanks for the amazing tool,

Now I have this #1592 TL;DR I'm building multiple docker images with please in our monorepo where all docker files are put in the root of repo because of the dependencies stuff. now, my question is I want to build docker image based on changes in repo so you know when CI runs not all docker images will push/build and only changed one push/build.

something like this:

subinclude("//pleasing//docker")

docker_image(
    name = "abc",
    dockerfile = "abc.Dockerfile",
    srcs = ["abc","efg","abc.go"],
    visibility = ["PUBLIC"],
    version = f'$(echo "$(git rev-parse --abbrev-ref HEAD)-$(git rev-parse --short HEAD)")'
)
docker_image(
    name = "xyz",
    dockerfile = "xyz.Dockerfile",
    srcs = ["xyz","efg","xyz.go"],
    visibility = ["PUBLIC"],
    version = f'$(echo "$(git rev-parse --abbrev-ref HEAD)-$(git rev-parse --short HEAD)")'
)

and in CI I'm running

./pleasew run //:abc_push
./pleasew run //:xyz_push

so now if there is a change in xyz directory, target abc is also running and building docker image. which is not appropriate because abc image/srcs has no change since it's getting list of srcs!!. so am I missing something or please is not doing git diffstuff

Is there a way to vendor all 3rd party dependencies to avoid requiring network access during bootstrapping? We are working on FreeBSD port and the build currently fails with

1 error occurred:
        * Get https://github.com/kevinburke/go-bindata/archive/46eb4c183bfc1ebb527d9d19bcded39476302eb8.zip: dial tcp: lookup github.com on 1.0.0.1:53: write udp 127.0.0.1:61403->1.0.0.1:53: write: permission denied

Build stopped after 40ms. 1 target failed:
    //third_party/go:_go-bindata-go-bindata#download
1 error occurred:
        * Get https://github.com/kevinburke/go-bindata/archive/46eb4c183bfc1ebb527d9d19bcded39476302eb8.zip: dial tcp: lookup github.com on 1.0.0.1:53: write udp 127.0.0.1:61403->1.0.0.1:53: write: permission denied

because network access is not allowed during build phase.

Module support is now included in Go 1.11 and will be on by default with Go 1.12 (now in beta). How will this effect please, do we need to support it?

On a side note, Bazels Go rules support an importpath variable. If we had something similar, we could move away from building everything in a single "virtual" gopath and decouple the filesystem layout from the import paths.

Certain targets are only required (and can only built on) for certain platforms. For example: certain dependencies might only be required by linux.

My current approach is an if, combined with a custom select_config rule:

if select_config([{
    "os": "linux",
    "cpu": "amd64",
}]):
    go_library(name = "logrus", srcs = [":_logrus#go_source"], cover = False, import_path = "github.com/sirupsen/logrus", visibility = ["PUBLIC"], deps = select({"//example/third_party/go/__config:darwin_amd64": [], "//example/third_party/go/__config:linux_amd64": ["//example/third_party/go/golang.org/x/sys/unix"], "default": []}))

The problem is: it's more generated code, and the buildifier package formats the target itself on a single line.

Is there a better way to represent platform specific targets? (It's not the end of the world, but it's hard to read and more changes in a VCS)

A follow-up from #1140: It might be beneficial to add gocloud into please, in order to allow blob storage to be used as a cache backend (so backends like AWS S3, Google Cloud Storage, or Azure Blob Storage could be used).

This would allow users who run please builds in different CI providers to connect to a remote blob storage for their cache (or run their own one! there's always the S3-compatible flavour of the week version).

Gocloud provides a common interface, so configuration is universal; however, it seems to call each services' specific SDKs below, so it might be a heavy dependency.

I know that I'm doing something that's against the rules of Please. But I've been doing the same thing in Bazel and it handles this use case well, so maybe Please could also do this.

The idea is to allow build_rule to produce outputs that are symlinks to files generated in the source tree, and make Please follow the symlink to determine if the rule is dirty.

Right now Please won't rerun the rule if the file that symlink points to changes or disappears. And Bazel does this.

Bazel still warns you if you're using genrule for that, but if you're doing it via a custom rule - it works. Would be great if Please could do the same.

When please is installed with Homebrew and there different Please versions in use, Please always downloads a new copy differing from the current version.

I guess it's related to Homebrew.

I just learned of 'please' today, and I notice you're calling CPython 2.x in process. You might be interested in a pure-Go implementation of Skylark here: github.com/google/skylark. It has certain benefits relative to Python:

• no GIL, so you can execute multiple threads in parallel, which can make the loading phase (BUILD file execution) and dependency analysis (rule.implementation function execution) much faster.
• restricted import, no OS access, etc
• control over mutability, so no possibility of a data race, despite familiar imperative paradigm.
• compatibility with Bazel.

I gave a talk on it: https://www.youtube.com/watch?v=9P_YKVhncWI

cheers alan

For reference I am using MacOS.

This issue only exists for the go_binary rule and third party dependencies which are added as library paths through command substitution. i.e. third party dependencies defined outside of the root third_party/go/BUILD.plz. The go_library rule works only because it's not actually quoting the file paths due to a subtle bug.

$(for i in $(find "$TMP_DIR" -name pkg -type d); do echo -n " -I \"$i\"/{CONFIG.GOOS}_{CONFIG.GOARCH} "; done)

The snippet above in the python go_library rule becomes the following in the actual shell.

$(for i in $(find "$TMP_DIR" -name pkg -type d); do echo -n " -I "$i"/darwin_amd64 "; done)

The escaped quote is lost and instead we get string concatenation which is probably not what was originally intended. In regards to the go_binary rule it is actually quoting the file paths. However, because it is being injected via command substitution it does not work properly. There are a couple issues here.

Issue 1) The output of command substitution is split on whitespace regardless of quotes within the output. So, for example, a file path which includes spaces printargs $(echo '"foo bar\baz.txt"') would become the following arguments.

arg 0: "foo
arg 1: bar\baz.txt"

Issue 2) The quotes within the command substitution output are preserved. So, if we have -L "foo/bar/pkg/darwin_amd64" it's going to attempt to look in a directory named "foo, which begins with a quote, and not the correct directory foo.

This fix removes the need for quoting by using null separated arguments instead and providing them to the link/compile command via xargs instead of command substitution. Once I began manually testing with file paths which included spaces I noticed that the _LINK_PKGS_CMD also didn't account for spaces so I fixed it in a similar manner.

I see here https://github.com/thought-machine/please/blob/master/src/please.go#L27 the import of package hashes instead of github.com/thought-machine/src/hashes as usual on Go

is there any way of importing the package using the full URL?

It seems like Please doesn't recognize situations when the output of a given target is modified from the outside after the build. I know this is an extremely weird thing to happen, but it can bite hard when using codegen targets and LinkGeneratedSources config option.

So if you accidentally modify the linked output, then Please will not warn you about it, and will silently skip the target during next build, which may lead to correctness issues. And when caching is enabled, even removing the output doesn't help, Please would still create the modified version of a file. The only way out of it is to force the build with --rebuild, but you have to know that you're facing this problem (which is quite hard if someone else accidentally modified the file).

I would expect Please to automatically recognize these situations and either issue a warning message, or just rebuild the target when this happens. Maybe with an opt-in configuration parameter.

Have been wanting this for a while; sometimes you see something but you need the previous build's logs to understand what's happened (e.g. if you're asking "why is this target building again", you ideally want all the details in the log of the previous time it built to compare the two, but that's just been stomped all over).

This doesn't do anything clever like gzipping old files and isn't configurable (log setup happens pretty much first thing so we don't have access to any config at this point). I imagine this will be sufficient but we can always do more later.

Hey folks! I was researching monorepo tools and found a link to Please at https://turbo.build/repo/docs/acknowledgements#inspiration--prior-art

There exists monorepo.tools which is maintained by Nx authors. This website does not feature Please and I think it’s a shame because your tool is quite cool and so definitely deserves to appear in the comparison table. I saw pantsbuild/pants added recently and it’d be great if you could poke someone from Nx too! 🙂

Thanks for working on Please and making it open source! 🚀

Draft PR fixing #2599

Unfortunately, we can't be sure that the package will be in the build graph when we build the target. Packages are added at the end of parsing the package. We now activate targets early for subincludes, and might actually build the target before we have finished parsing the package.

To fix this, we'd need to add packages to the graph in a pending state. We could potentially replace the pending packages map, moving the channel into the Packages struct.