3.20 introduced breaking change for ZodDiscriminatedUnionDef

I just wanted to note that 3.20, while claiming to have no breaking changes, did change the number of type arguments for ZodDiscriminatedUnionDef from 3 to 2. This led to breakages such as https://github.com/StefanTerdell/zod-to-json-schema/issues/31, which may be tricky to navigate in a cross-version-compatible manner.

I export literally everything from types.ts so people have an easier time building things on top of Zod. The downside is that there is virtually no change I can make that won't be "breaking" if someone relies on a particular type alias. For that reason, I consider the public API to be the z., the method signatures, and the internal structure of ZodError - the things that a typical user will interact with.
But historically I haven't considered the structure of Defs or the generic type signatures of each subclass part of the public API, hence "no breaking changes". This definitely makes it tricky to I'll take more care to minimize changes to the internals to account for the growing ecosystem of tools that rely on Zod.
That said, 3.20 is a very major release for Zod. I think it's likely that Zod will never move past v3, since it's been a year and a half, and I haven't encountered any reason to do a big rewrite or (public) API breakage. Despite that fact that its "minor", 3.20 is a really big release, I think the best move for ecosystem authors is to treat this as a major release, update to Zod 3.20, and specify<EMAIL_ADDRESS>in their peerDeps.

@colinhacks Why not release it as a 4, if you yourself consider it a big release? Not like you are running out of numbers any time soon.

I still count public types as part of the contract and standard semver expectations were arguably broken here. But for us, it's mainly that one library that bit us and it seems to be maintained, so I'm sure we'll be in the clear soon when they release a new version. Not a big deal. Just know that this approach implies a form of pain and risk as well. Both in terms of us getting compilation errors just as an effect of a dependabot minor bump, and  in terms of that utility library likely going to have a hard time supporting both pre-3.20 and post-3.20 at the same time.

RIP zod parsers around the world

Is this conversation still ongoing? If not, I'd like to close this issue.


Test regex environment (regex 101)

This feature is to test the regex patterns provided in the regex101 environment to test the authenticity and correctness of the patterns to avoid future ambiguity

Hi, could you assign this to me, I can test these

Hey, sorry for the delay.
Sure you can get started with this. @nikhilnrr


Ensure uniqueness in suppressions

This PR addresses an issue with duplicate items in the suppressions array, which was causing complaints from upload-sarif. By ensuring uniqueness in the suppressions array, we prevent duplicate items from being pushed. This improves the reliability of the SARIF upload process and resolves the issue reported by upload-sarif.
Changes made include implementing a mechanism to enforce uniqueness in the suppressions array, ensuring that each item is added only once.
close #86

please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@microsoft-github-policy-service agree


specifying multiple creators

In the only examples there is a single creator
can a list be provided using yaml list syntax? the linkml doesn't declare this as multivalued.

Example: tsv file to validate. Error:
--- Logging error ---
Traceback (most recent call last):
File "/Users/HHegde/Desktop/gitRepo/mapping-commons/sssom-py/sssom/io.py", line 90, in validate_file
from_tsv(file_path=input_path)
File "/Users/HHegde/Desktop/gitRepo/mapping-commons/sssom-py/sssom/parsers.py", line 34, in from_tsv
meta = _read_metadata_from_table(file_path)
File "/Users/HHegde/Desktop/gitRepo/mapping-commons/sssom-py/sssom/parsers.py", line 421, in _read_metadata_from_table
meta = yaml.safe_load(yamlstr)
File "/opt/anaconda3/envs/sssom--py38/lib/python3.8/site-packages/yaml/init.py", line 162, in safe_load
return load(stream, SafeLoader)
File "/opt/anaconda3/envs/sssom--py38/lib/python3.8/site-packages/yaml/init.py", line 114, in load
return loader.get_single_data()
File "/opt/anaconda3/envs/sssom--py38/lib/python3.8/site-packages/yaml/constructor.py", line 49, in get_single_data
node = self.get_single_node()
File "/opt/anaconda3/envs/sssom--py38/lib/python3.8/site-packages/yaml/composer.py", line 36, in get_single_node
document = self.compose_document()
File "/opt/anaconda3/envs/sssom--py38/lib/python3.8/site-packages/yaml/composer.py", line 55, in compose_document
node = self.compose_node(None, None)
File "/opt/anaconda3/envs/sssom--py38/lib/python3.8/site-packages/yaml/composer.py", line 84, in compose_node
node = self.compose_mapping_node(anchor)
File "/opt/anaconda3/envs/sssom--py38/lib/python3.8/site-packages/yaml/composer.py", line 127, in compose_mapping_node
while not self.check_event(MappingEndEvent):
File "/opt/anaconda3/envs/sssom--py38/lib/python3.8/site-packages/yaml/parser.py", line 98, in check_event
self.current_event = self.state()
File "/opt/anaconda3/envs/sssom--py38/lib/python3.8/site-packages/yaml/parser.py", line 438, in parse_block_mapping_key
raise ParserError("while parsing a block mapping", self.marks[-1],
yaml.parser.ParserError: while parsing a block mapping
in "", line 1, column 1:
This mapping was created followi ...
^
expected , but found ','
in "", line 4, column 52:
... //orcid.org/0000-0003-1336-5554", "https://orcid.org/0000-0001-9 ...
this was due to this line:
#creator_id: "https://orcid.org/0000-0003-1336-5554", "https://orcid.org/0000-0001-9625-1899", "https://orcid.org/0000-0002-6601-2165", "https://orcid.org/0000-0003-1144-0290", "https://orcid.org/0000-0002-8083-6048", "https://orcid.org/0000-0003-3770-3714", "https://orcid.org/0000-0002-4366-3088", "https://orcid.org/0000-0002-4236-0384", "https://orcid.org/0000-0001-8815-0078", "https://orcid.org/0000-0002-2996-719X", "https://orcid.org/0000-0001-9401-8460", "https://orcid.org/0000-0003-1691-239X", "https://orcid.org/0000-0001-6215-3617", "https://orcid.org/0000-0002-3237-4547", "https://orcid.org/0000-0001-7087-2646"
When I replaced the ", " between the ORCIDs by a whitespace, it fixed the issue and the file seemed valid.
There is a need to make the error more informative. The validate code needs to address this.

Are formalizing how creators are specified? If so, can we do something like this:
#creator:
#  - William D. Duncan [https://orcid.org/0000-0001-9625-1899]

or
#creator:
#  https://orcid.org/0000-0001-9625-1899: William D. Duncan

issue also mentioned in https://github.com/tdwg/gbwg/issues/69

I would kind of prefer this was solved at tool level rather than in the metadata itself.. It will be really hard to provide validation if we allow complex patterns like this - think that the same metadata item also goes into columns (its not required to have creator up on mapping set level).


Can't loading from certain remotes, possibly those containing multiple "-"

Hello,
I use your monitor on 3 different hosts. 1 of those hosts works consistently, and 2 of them fail to work consistently. The names might be sensitive, but the ones that work are in the format aaaaaaaa-review and the ones that dont are in the format aaaaaa-aaaaa-review.
Could there be an issue with hosts with names with multiple '-'?
If that's not making sense, how can I help debug this issue?
Thanks

Hello,
In my experience, the most common reason why some hosts are not working is that the JSON API is disabled for the particular gerrit installation or it is using a version of the API that is incompatible with the extension.
One way to debug is to inspect the network traffic generated by the extension when it communicates with the gerrit instance. You can do this by going to chrome://extensions, clicking on "Details" for "Gerrit Monitor", then click on the link "background.html" in "Inspect views".
This should open a new window with developer tools. Then you can inspect in the network tab the requests and the responses from the servers. Requests are sent periodically (every 5 minutes) or when you click on the badge in the Chrome UI. In the network tab, for each instance, you should see a request for /account/self followed by a request for /changes/?q=status:open+...
The reply in each case should be a JSON file (first request will contain information about the logged in user, second one will contain the list of changelist are currently opened and may require your attention).
If the content of those requests is as expected, then the issues lies in the extension. If it is not, there may exists an issue with the gerrit configuration. In the first case, we can try to debug together to see what is causing the extension to fail.
Cheers,

I'm able to observe this error;
Access to XMLHttpRequest at '[redacted]' (redirected from '[redacted]') from origin 'chrome-extension://leakcdjcdifiihdgalplgkghidmfafoh' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.
I've emailed you a couple of unredacted screenshots.
Hope that helps,
Graham

I decided to reinvestigate this, and discovered that it's caused by a HTTPS upgrade redirect.
http://foo-review.googlesource.com/  (bad)
vs
https://foo-review.googlesource.com/  (good)
Derp.
I'll close this now. Hopefully this thread helps someone else.


BEAM-3894: Add Protocol Buffer support

This allows the Go SDK to use protocol buffer messages as a concrete
type. This creates a compile-time dependency on the protocol buffer
libraries. Internally, to build the SDK, you'd need protobuf support
to run "go generate" but this is a more direct dependency.
Adding a registration hook could move this dependency to be handled
differently, but this dep is lightweight and should be OK for the
immediate future.

@herohde @lostluck

I'm not following the points in the "On a similar vein" paragraph.
If a Go struct has a proto message as a field, the resulting struct is still concrete and serializable. Unfortunately, it'd devolve to encoding the proto using the JSON coder based on the top-level type. This is unfortunate, but it would work. I'm not sure it needs to be disallowed. I see how having the coder registry would alleviate this situation: the top-level struct would be JSON encoded, but the proto message member would be looked up and use the proto encoding for that "subtree"
I'm confused by the phrase "non-concrete codeable types." Of the non-concrete types, we have Containers, which are serialized based on its underlying Concrete type, Universals which aren't actually serialized, and Composites, which are a custom encoding based on the underlying types. What did you mean by this phrase?

Added the registrations.
I am still working on a test case running against Cloud Dataflow to verify the serialization actually works. The direct runner only requires the IsConcrete method to be working in order to handle protocol buffers; I need to test against a runner that will actually serialize data.

This version has been tested internally to Google. The decode routine did have a bug where the instantiated type wasn't correct. This is resolved and I've validated the messages are serialized and deserialized using the proto codings.
I'll still continue to develop a Cloud Dataflow suite, but if we want to submit this now, I feel confident in this code.

LGTM.
By "non-concrete codeable types", I meant types that require a user-provided coder to work (= are currently classified as Invalid). Protobuf is one example. I expect some interfaces will also fall into this category. While protobufs might play well with JSON as fields, it won't be the case in general. That's why I'm thinking we may want to add a new class to handle such types. But that is something to consider as a part of a proper coder registry.

Got it! Said differently, Concrete will just mean the set of types that can be encoded "natively" and the new type, say UserCoded, will capture the concept that's been introduced into IsConcrete.

Yep

R: @tgroh


Support struct like proto3 'one_of'

This is not compatible with thrift, and will need extension to the
IDL, Suggested syntax:
struct MyStruct {
    1: optional one_of type {
        2: optional string username;
        3: optional i32 user_id;
    }
}

This is based on the proto3 one_of feature, which is a re-purposing of the proto2 group.
May only be used in .pvd files to avoid mixing in with .thrift.

This can be solved in thrift using a "one_of" annotation.
struct MyStruct {
        2: optional string username (one_of = "type");
        3: optional i32 (one_of = "type");
}

Which will generate the method camelCase(name) + Field and camelCase(name) + FieldIsSet (in this case typeField). Reserved (not allowed) names are: [get, set, num, has], just in case someone has also added the field field, which is not reserved.
And The union message type can be reclassified to force the one_of annotation to be "union".


Stablize metadata flags test

_metadata_flags_test.py still flakes around 1 % in our dashboard.
This PR applies the same fix as https://github.com/grpc/grpc/pull/23007 to _metadata_flags_test.py. Hopefully, the last bit of flake will go away.
We still need to close the socket, otherwise the channel will stuck at CONNECTING state.

Known failure: https://github.com/grpc/grpc/issues/23047


feat: release v3.2.0

Changes included in this PR:

update docs (readme, comp matrix, release notes)
update tests
refactor CI to use Kind

Resolves: 504

Talking with Sam, I understood that bumping harbor version is out of scope for this release and not currently required. Right @nutellinoit?

As discussed, I updated the release notes to clarify that this release is purely for Kubernetes compatibility testing and doesn't include changes.


Sheets prerelease fixes

Codecov Report

Merging #7 into master will decrease coverage by 0.33%.
The diff coverage is 23.07%.

@@            Coverage Diff             @@
##           master       #7      +/-   ##
==========================================
- Coverage   61.42%   61.09%   -0.34%
==========================================
  Files          71       71
  Lines        2437     2457      +20
==========================================
+ Hits         1497     1501       +4
- Misses        940      956      +16

Impacted Files
Coverage Δ

pygsuite/sheets/sheet.py
33.33% <18.18%> (-0.84%)
:arrow_down:

pygsuite/sheets/worksheet.py
32.63% <26.66%> (-1.90%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3add84b...65440f7. Read the comment docs.


cloneDeep data when loading into a collection.

Protects nested fixtures from getting mutated during tests.
Fixes #1071.

restarting master build in case it's something there

Hm, master seems fine. Could you investigate the failing tests?

@samselikoff yeah weird that! sure I'll see what's causing the failures.

@stuartc I'm running into this issue as well while trying to upgrade. Have you had a chance to dig into this any further? I'll likely be spending some time on Friday on this.

Believe there's something here with ember-inflector breaking changes. Could someone could dig into this & summarize our possible options for me?

@HeroicEric unfortunately I haven't managed to get time to check it out - I'm using my fork for a project without any issues - I won't be able to get around to this until the weekend.

@samselikoff I reran the build and this seems to be passing now

I rebased against master a few days ago, and pushed - I see the Chrome Canary travis jobs are set to 'allow failures', so the tests pass. So this is good to go if you're happy @samselikoff

nobody to do the necessary?

@samselikoff just rebased against master, would be great to get this in a release. :)

This has been fixed since loadData does a _cloneDeep now.


Incorporate utils.bash into each executable to help simplify packaging for Linux and other platforms.  This adds to PR #32

Incorporate functions from utils.bash into kubectx and kubens
Remove utils.bash (no longer needed)
Updated README.md

Both executables locally tested and are in proper working order.

Thanks, now I suspect the Homebrew formula needs updating: https://github.com/Homebrew/homebrew-core/blob/8d530a70f8fcf02129d924090d73efbe12ff438d/Formula/kubectx.rb#L17
Once I tag a release, it will break the formula. Let me think how we can coordinate this.