tcncloud / wollemi Goto Github PK

Given a library and a test target that looks like this:

go_library(
    name = "lib",
    srcs = glob(
        [
            "*.go",
        ],
        exclude = ["*_test.go"],
    ),
    # ...
)

go_test(
    name = "test",
    srcs = glob(
        [
            "*_test.go",
        ],
        exclude = ["external_test.go"],
    ),
    deps = [
        ":lib",
        # ...
    ],
)

gofmt removes the :lib dependency. I assume it wants the non-test files to be added to srcs, however that also requires to add deps directly to the deps section which can be rather large in number.

Is this the intended behavior? Is this a bug?

I'm still looking if it happens everywhere or only in certain targets, but this is definitely a change in behavior since 0.2.1.

Remote file can be used to install wollemi like so:

WOLLEMI_VERSION = "v0.2.1"
remote_file(
    name = "wollemi",
    url = f"https://github.com/tcncloud/wollemi/releases/download/{WOLLEMI_VERSION}/wollemi-{WOLLEMI_VERSION}-{CONFIG.HOSTOS}-{CONFIG.HOSTARCH}.tar.gz",
    extract = True,
    binary = True,
)

Wollemi doesn't always understand some of our build defs and as such ends up creating rules when it shouldn't. I think for our usage, we'd probably want to just use it to update the existing rules. Would be nice to have this as a flag. WDYT?

I encountered an issue where when a package has all its dependencies removed, wollemi won't touch the deps attribute and it will leave all deps there.

I think it's caused by this check:

Since the result is no deps, the check fails, and it doesn't clear the deps.

What is the correct format of the .wollemi.json? The examples in the README are not valid JSONs and it's not clear how the config file should look like.

I think I found a race condition in configuration loading, at least that's what the following issue suggests:

When using known dep config, wollemi seem to miss config files sometimes. The following example shows that when wollemi complains about a dependency not being resolvable, the known dependency map is empty, whereas prior executions are successful:

❯ ../../../contrib/wollemi/plz-out/bin/wollemi gofmt
❯ ../../../contrib/wollemi/plz-out/bin/wollemi gofmt
ERRO[0000] could not resolve go import                   build_rule=example go_import=emperror.dev/errors/match known_dependencies="map[]" path=example2
ERRO[0000] could not resolve go import                   build_rule=example go_import=github.com/containerd/containerd/sys known_dependencies="map[]" path=example2
ERRO[0000] could not resolve go import                   build_rule=example go_import=github.com/golang/snappy known_dependencies="map[]" path=example2
ERRO[0000] could not resolve go import                   build_rule=example go_import=github.com/mattn/go-sqlite3 known_dependencies="map[]" path=example2
ERRO[0000] could not resolve go import                   build_rule=example go_import=github.com/opencontainers/runc/libcontainer/system known_dependencies="map[]" path=example2
ERRO[0000] could not resolve go import                   build_rule=example go_import=golang.org/x/sys/unix known_dependencies="map[]" path=example2
ERRO[0000] could not resolve go import                   build_rule=example go_import=google.golang.org/grpc known_dependencies="map[]" path=example2
ERRO[0000] could not resolve go import                   build_rule=example_test go_import=github.com/stretchr/testify/assert known_dependencies="map[]" path=example2

I'm looking for the root cause, but I wanted to open an issue first.

I've spent some time with releasing software with please recently and came up with the following (you can see everything in this repo: https://github.com/sagikazarmark/please-go-modules/):

• Release artifacts (ie. tar.gz files) are all built by Please running on GitHub Actions (see this target)
• Checksum is automatically calculated for each archive
• The release notes contain a Please target that downloads the archive for the right os and architecture and there are checksums in there as well (see these targets)
• Finally, the artifacts are uploaded by a custom script using the official GitHub CLI

There is also a target in the readme that points to the latest release (quite literally to the latest release without an actual version in the URL).

For this to work, the archive names cannot contain the version:

https://github.com/sagikazarmark/please-go-modules/releases/latest/download/godeps_{CONFIG.HOSTOS}_{CONFIG.HOSTARCH}.tar.gz

vs

https://github.com/tcncloud/wollemi/releases/latest/download/wollemi-v0.7.0-{CONFIG.HOSTOS}-{CONFIG.HOSTARCH}.tar.gz

This setup is actually not new, I only added the release notes recently and it works quite well for months now. Let me know if this is interesting for you.

Please added embed support to the go_library rule: you can now add a resources attribute containing a list of files to embed into the library.

Wollemi could generate that attribute automatically based on information available in the source files.

I'm trying to introduce Please to our projects at Banzai Cloud. Sadly, the modules support of Please is not perfect yet, so I decided to take an iterative approach and embrace the incremental build features in small steps.

I got to a point where I have custom go_library, go_binary and go_test targets that rely on the go build tool and build cache. This is good enough until go modules support is mature enough to use.

I wrote a custom tool to generate the initial go_library and go_test rules, but I'd love to use wollemi instead. The only thing that keeps me from doing it right now is that it complains about the missing third party dependencies.

It would be nice to have a way to disable the resolution of third-party dependencies entirely, so that wollemi can focus only on the packages inside the project.

I know this is somewhat controversial as it's not the "Please way", but I think the iterative process of introducing Please to a project is the right path as it can deliver value early compared to spending weeks on migrating the entire build process. Having support for that in wollemi would be cool.

What do you think? Having spent some time with Go list and packages recently, it doesn't feel like a large change.

Can you tag a new release?

Hey guys, first off I'm eternally grateful for this tool otherwise I would be in a very sorry place for this v16 migration. That being said there are a few niggles that need fixing before we can use the tool here at Thought Machine. I'm very happy to help out once I get v16 out the door. With that being said, here they are:

1. Wollemi doesn't support GOPATH based projects very well. Ideally it shouldn't need to know about the go path. I've developed a helper tool to resolve go imports to build rules so you should be able to use that instead of guessing based on the go path.
2. We put tests in their own directory i.e. foo/foo.go and foo/test/foo_test.go however Wollemi will generate extra go_library() build rules for us.
3. We have a service_acceptance_test() build rule that wraps go_test() but injects some test main stuff to help with our integration tests. Wollemi doesn't understand this so generates us go_test() targets (and doesn't update it's deps). I wonder if we can give it a list of rules to work on, and default this to go_test(), go_library(), and go_binary() but we can add service_acceptance_test().
4. We sometimes have multiple go_test() targets in a package. In this case, wollemi adds a go_test(name = "test", ...) to our package instead of updating those tests. Ideally it should be able to look at the srcs to each rule.

To make it easier for you guys, I plan on labelling go rules with the packages they generate. There's then this code I wrote that consumers the output of plz query graph:

https://gist.github.com/Tatskaari/2820811a0de25b6a9a86d2de636015a2

I'll clean this up and get this out in a Please release so you guys can use that to resolve imports to build targets.

Other than that, it works pretty great and has helped massively. If we can work through these niggles, I will have a hoard of happy developers here at Thought Machine.

Please added an fmt command in 15.6.0: https://github.com/thought-machine/please/releases/tag/v15.6.0

It uses a modified version of the buildifier tool library.

Hi there! 👋🏻 amazing tool btw!
As I tend to use vscode (and was a bit jealous of that vim integration!) I've created a little vscode extension that runs Wollemi on file save.
Project link: https://github.com/jamesjarvis/vs-wollemi
VSCode marketplace link: https://marketplace.visualstudio.com/items?itemName=jamesjarvis.vs-wollemi

I was wondering if I could get your opinions on it? Thanks!

Installation instructions for a please rule have been removed here: b344d6a

The commit message references an issue, but I couldn't find any more details about it.

What is that issue exactly? It's be nice to add that installation method back.