Problems:
- When iterating over an empty string in a list comprehension, the
result is an empty string. This is a bug, it should be an error.
- When iterating over a non-empty string in a list comprehension, the
expected and unexpected types in the error message are swapped.
- Error messages mention "std.flatMap" when object/list comprehensions
would iterate over a value that is neither array nor string.
```
$ jsonnet --version
Jsonnet commandline interpreter (Go implementation) v0.21.0-rc2
$ jsonnet -e '[a for a in ""]'
""
$ jsonnet -e '[a for a in "b"]'
RUNTIME ERROR: Unexpected type array, expected string
<cmdline>:1:1-17
During evaluation
$ jsonnet -e '{[a]: 1 for a in 2}'
RUNTIME ERROR: std.flatMap second param must be array / string, got number
<cmdline>:1:1-20
<cmdline>:1:1-20
During evaluation
$ jsonnet -e '[a for a in 1]'
RUNTIME ERROR: std.flatMap second param must be array / string, got number
<cmdline>:1:1-15
During evaluation
```
FWIW, the C++ implementation does not have any of these problems. It
gives:
```
RUNTIME ERROR: In comprehension, can only iterate over array.
```
In the Go implementation comprehensions are desugared to a call to
std.flatMap which does accept a string in the "arr" parameter.
The fix: Desugar comprehensions to a call to a new hidden builtin which
only accepts arrays.
Use the GitHub setup-go action to install Go, as it is not in the
Mac OS runner images by default.
I tried but failed to get a Windows wheel build working, so that
remains disabled for now.
Otherwise if the submodule is initialized Bazel will try to build
it when running commands like bazel test //...:all. But that doesn't
work because the cpp-jsonnet directory is not part of the same
bazel module.
Perhaps there is a better way to fix it but just ignoring the
cpp-jsonnet directory seems to be ok.
Bazel 7 is currently in maintenance and supported to the end of 2026.
The CI build should require an up-to-date lockfile so that we can try
to catch before merging if Bazel dep changes are made without the
corresponding lockfile change.
* chore: Update dependency versions
* Downgrade crypto to fix bazel CI
* Switch to Go 1.23.7 and update dependencies
Signed-off-by: Andrii Korotkov <andrii.korotkov@verkada.com>
- Checkout with submodules, otherwise the sdist won't include libjsonnet.h
- Install golang in the cibuildwheel build container.
- Skip musllinux build; it's not working for me.
- Skip Windows platform builds; they're not working for me.
It would be nice to get the other platforms working but I have already
spent hours on this and haven't succeeded yet. Previous go-jsonnet
releases on PyPI didn't have prebuilt wheel packages anyway, so it's
still strictly better to have some rather than none even if not all
platforms are covered.
This changes the bazel module dependencies so that the C++ jsonnet
repo dependency (which is actually used as the source for the
standard library and nothing else in the Bazel build) comes from
a specific commit of the jsonnet repo, rather than depending on
the 'published' jsonnet 0.20.0.
The two repos are tightly coupled anyway so I think this more
accurately reflects the situation. Particularly since the C++ repo
is also linked (at a specific commit) as a git submodule, which
is used for non-Bazel build and testing.
It was added in Jan 2020 and apparently has never been updated since
then. It refers to Bazel 1.2.1 which is long out of date (Bazel 5 is
the oldest still maintained version, and Bazel 8 is the current
active version).
This corresponds to a similar commit on the C++ jsonnet repo:
a02a615def
The is intended to make it easier for me to trigger running CI on
existing pull requests.
This includes the stdlib additions in
https://github.com/google/jsonnet/pull/1187
Also updates golden files for go-jsonnet tests; the changes
to the goldens are mostly changes to error locations from
the standard library.
The `valueToString` operation introduced by #742 is incompatible with the way
the implementation from #739 as it tries to manifest an object from stack while
the implementation needed by the debugger returns the value as-is without
further evaluation.
