Improve txtar DX

[moul]

Since we're increasingly using txtar, both as an integration test system and a means of sharing self-contained complex examples (#1262), I propose enhancing the txtar experience for developers. Here are some suggestions:

• Explore a suitable .gitattributes linguist language from this resource: https://gist.github.com/moul/113c2cc8bb27ce80969995192ddb4c7f.
• Consider configuring .editorconfig or sharing code snippets in CONTRIBUTING.md.
• In any case, update CONTRIBUTING.md to provide context and examples. For instance, highlight the effectiveness of running a specific txtar that delivers exceptional speed.
• Are there any other ideas worth considering?

cc @gfanton

[moul]

• Allow having txtar files alongside .gno files in examples/ folder.
• Add more test addresses by default (test2, test3, test4), and make it easy to use them.

[gfanton]

Explore a suitable .gitattributes linguist language from this resource.

I didn't examine in detail, but we can likely add a linguist directly to GitHub to support these files. It appears we need at least 200 unique repositories using this extension to submit a new one, which might already be possible given the fact that txtar was existing before gno.
In any case we can temporarily use one of the linguists you suggest.

Allow having txtar files alongside .gno files in the examples/ folder.

I actually like the idea of having a specific testdata directory as a subfolder of the current working directory. However, we might not enforce this. Instead, I suggest we create a gno testscripts command that can accept folders/files as arguments, similar to the go test command.

Based on recent experiences, I am exploring better ways to configure gnoland node from txtar. One idea is to start the node automatically with some sane defaults, but also allow explicit configuration using files like .env or config.json, or both, directly inside the .txtar:

# The node is already started.

# Execute some commands.
gnokey addpkg ...

-- myrealm.gno --
package hello

func Render(path string) string {
    return "hello world"
}

-- .env --
# gnoland config
GNOLAND_START_MINIMAL=true

# balance
GNOLAND_BALANCE_USER_test2=100000ugnot
GNOLAND_BALANCE_USER_test3=100000ugnot
...

With this approach, we can easily create users directly or update configurations as needed.

[jaekwon]

I would avoid using environment variables for input, and discourage its usage by not supporting it where at all possible.
Environment variables are prime candidate for hacking due to random behavior from various bash systems.
It's like the global of globals, and it's already full of other shit.

I much prefer explicit --flags, or files. Anything but environment variables.

My main thing with tests is this:

I just want "make test" to work as expected, at the root, and at the individual project levels. At the root it should just pass any options and call make test individually.

Anyone who pulls the codebase should be able to get make test passing, and go test ./... should all work as expected too.
Anything else and it fails from a developer UX perspective.

[jaekwon]

The test data should not be compiled into the same binary as the gnoland binary.
They should be built completely independently. Any association will lead to security issues.
Testing must never compile into the production build.
Can these integration tests be instead implemented as regular Test*() tests?

[gfanton]

Can these integration tests be instead implemented as regular Test*() tests?

They already are, and for now, they are not part of the gnoland binary. Even though it might look like bash, txtar is different and should not be compared to it, as it runs on the golang runtime with its own specifications. Its aim is to be simple; you cannot use if, &&, |, ;, etc.

Anyone who pulls the codebase should be able to get make test passing, and go test ./... should all work as expected too. Anything else fails from a developer UX perspective.

I totally agree with this. txtar is actually running inside the Golang standard test, so running go test ./... already works without any additional configuration.

The test data should not be compiled into the same binary as the gnoland binary.

That's fine. The gno testscripts I suggest could be moved to a gnodev binary (or something else in the contribs folder). I just want a way for people to easily run txtar files from outside the gno repository.

I would avoid using environment variables for input, and discourage its usage by not supporting it where at all possible.

It's not yet implemented, but I intended to use environment variables to create something that users can easily copy and paste in a bash environment. I understand that we shouldn't use this in production, but it can be handy in a testing environment. I don't mind using something else, like flags.