Upgrading to communication-react 1.7 beta version is breaking a bunch of unit tests

Describe the bug; what happened?
After upgrading to communication-react beta version and its chat and calling dependencies, existing tests that use react testing library user event are all breaking with the following error:
 TypeError: Cannot read properties of null (reading 'document')
      at la (../../node_modules/@azure/communication-react/dist/dist-esm/northstar-wrapper/src/index.js:2:1579

If I revert back to the old version of communication react i.e 1.5.0 and other lower versions of communication-calling and communication-chat, all tests start to pass.
What are the steps to reproduce the issue?
After installing the packages mentioned above. Just write a unit test and use jest with @testing-library/user-event for testing some behavior around click on a button. e.g:
    const user = userEvent.setup();
    await user.click(screen.getByText("TestButton"));

What behavior did you expect?
If applicable, provide screenshots:

In what environment did you see the issue?

@azure/communication-react npm package version (if applicable): 1.7.0-beta.2

@azure/communication-calling npm package version (if applicable): 1.15.1-beta.1

@azure/communication-chat npm package version (if applicable): 1.3.2-beta.3

OS & Device: Windows 11

Is there any additional information?

Hi @sayayinR, can you share your jest config file as well as your node version? Could you also check your jest configuration has testEnvironment set to a browser environment, such as jsdom
testEnvironment: 'jsdom'

@JamesBurnside thanks for the reply,
Node version is 18.17.1
Test env is set to:   "jest-environment-jsdom",
Below is the whole jest.config
import type { Config } from "@jest/types";

const config: Config.InitialOptions = {
  roots: ["<rootDir>/src"],
  preset: "ts-jest",
  setupFiles: ["<rootDir>/.test/jest.init.ts"],
  setupFilesAfterEnv: ["@testing-library/jest-dom/extend-expect", "jest-extended/all"],
  testEnvironment: "jest-environment-jsdom",
  testRegex: "\\.(test|spec)\\.tsx?$",
  moduleFileExtensions: ["ts", "tsx", "js", "jsx", "json"],
  collectCoverageFrom: ["./src/**", "!./src/**/*.stories.tsx", "!./src/**/*.dev.stories.tsx", "./test/**"],
  coverageReporters: ["cobertura", "clover", "json", "lcov", "text"],
  moduleNameMapper: {
    "\\.s?css$": "identity-obj-proxy",
    // Force module uuid to resolve with the CJS entry point, because Jest does not support package.json.exports. See https://github.com/uuidjs/uuid/issues/451
    uuid: require.resolve("uuid"),
    // Fix for an existing issue with proxy-memoize when "esModuleInterop": true, https://github.com/dai-shi/proxy-memoize/issues/42
    "^proxy-memoize$": "<rootDir>/node_modules/proxy-memoize/dist/wrapper.cjs",
    nanoid: require.resolve("nanoid"),
  },
  testTimeout: 60000,
};

export default config;

Thanks for sharing that. Some of our developers have hit this issue internally as well and found any function from @testing-library/user-event that calls fireEvent.mouseDown to trigger this error, we found all keyboard events from that same library to work.
Our best reasoning to what is happening is an error occurs causing jest to clean up the jsdom objects, then an async function/microtask is trying to subsequently access the package and hence the document object (the changes in communication-react v1.7 triggered document access at import time). We hoped that https://github.com/jestjs/jest/issues/12670 would resolve this issue but unfortunately it did not.
We ultimately avoided using the userevent.click events and opted for either keyboard events or fireEvent.click APIs instead as a short-term workaround and this is our best suggestion for what to do today. We are open to implementing a more concrete fix if you can determine the underlying reason for what is occurring.
However, we are in the process of removing the package were that error originates #3427, I've test on this branch and we no longer hit see this issue with the fluent northstar library removed. Once this PR is in and we release a new version that should resolve this issue for you. Please note this is a larger change that could take some time to check in.

Sounds good, I ll try out the the couple of options you suggested. Thank you for a prompt response.

As #3578 has now been completed and released in 1.9.0-beta.1 this should be fixed. We are currently working on releasing 1.9.0 with the fix also.


Backport fixes to v1

The following PRs might need to be backported to v1.

#100
#101

Closing the issue since the v2 push is not ported to v1.


[WIP] Support SNPE DLC quantize

TODO: fix https://developer.qualcomm.com/forum/qdn-forums/software/qualcomm-neural-processing-sdk/36055

The library loading problem was due to some python configuration so unrelated.
Some are working so merging


[FLINK-10453][travis] Move hdp 2.4 tests to cron jobs

What is the purpose of the change
This PR removes the Travis hadoop 2.4 profiles. My intention is to move these into daily cron jobs by adding another cron-master-hdp2.4 branch, as seen here: https://github.com/zentol/flink/tree/cron-master-hdp24
Given that most contributions are largely independent of hadoop this is a good opportunity to reduce our travis usage.

.travis.yml conflicts. Please rebase.


Simplify code and configuration

Hi,
I really like the app, so I started to play with the code. Unfortunately, your IDE configuration is different from mine, so I had to regenerate the .idea folder. I also excluded it from git, so that I don't accidentally overwrite yours. This should also be a good idea if anyone else wants to work on the code.
My first "real" commit is a small simplification of the string formatting - Java can add leading zeros to a number, so you don't have to.
Hope you like it. I'll probably add some other stuff, too, if you're okay with that :)

Hi,
Thank you for the contribution. I have C++ background and I'm not yet familiar with all Java features.
Some other stuff is anytime welcome :)
I'll test and merge soon. I don't have any automated tests yet.

Thank you :)
I have some experience with Java, so this hopefully helps, even though I haven't really worked with Android yet besides some tutorials.
In other news, I've started to clean up the code a bit, to make it more testable.


move mysql creds to compose env variables

closes #75

buellerrrrrr

hi!

ping @endophage

https://github.com/docker/docker/pull/9176#issuecomment-99542089 🙊👼

@thaJeztah the irony is not lost on us :)
The major difference is between doing it/condoning it for everyone using docker.

@diogomonica I know, sorry, couldn't contain myself :smile:
(change LGTM)

@RichardScothern Aaron is using a different compose file to deploy (he builds his own images from those we push to hub and deploys those). We want the files as they exist in the repo to be runnable locally so contributors can get up and running easily.
With that in mind, we probably need to revert the changes for ansible.

@endophage I'm aware of this :)  What do you want to do with this PR? :cake:

@RichardScothern you personally, nothing, just addressing your earlier comments.

so can i go back to what i had here originally ;) https://github.com/docker/notary/pull/76#discussion-diff-34908672

updated

does docker-compose up work with this config? (as in, are we able to point notary to it and it works?)

yessir

but you may want to verify for yourself

rebased..

come on people

Now that I've been playing with Ansible, there's basically no difference in whether we include the variables in a config file or as ENV variables, they will get defined in the same place then the reefer tool is responsible for either passing them to the process we run or placeholding them into a config . However for local dev, it seems much easier to include them in a config. Thoughts?

@jfrazelle going to close this as it'll be superceded by this PR https://github.com/docker/notary/pull/185
That PR will allow trust to take full control over deployments once I finish the integration.


Events: Display TBD if location is empty or null

event-item

checks if location is null or empty, displaying TBD if it is null, empty, or white space

hopefully small and easy fix :^)
Resolves #416

What an absolute king taking into consideration all edge cases and treating it like a leetcode problem


[BUG] Non-ASCII characters in file names come out as garbage in Windows Explorer

Describe the bug
Special characters (äöüè ...) in the file name are not displayed correctly with Windows Explorer. Even if the file is unzipped by the Windows own tool the filename is not displayed correctly. However, unpacking by 7zip works correctly.
If the ZIP file is created with JSZIP, the file names are displayed correctly with the Windows tools.
Example:

expected filename: äöüè___milano.gif
displayed filename: ├ñ├Â├╝├¿___milano.gif

To Reproduce

async function downloadTestZip() {
  // define what we want in the ZIP
  const intro = { name: "äöüè_milano.txt", lastModified: new Date(), input: "Hello. This is the client-zip library." }

  // get the ZIP stream in a Blob
  const blob = await downloadZip([intro]).blob()

  // make and click a temporary link to download the Blob
  const link = document.createElement("a")
  link.href = URL.createObjectURL(blob)
  link.download = "test.zip"
  link.click()
  link.remove()

  // in real life, don't forget to revoke your Blob URLs if you use them
}

Expected behavior
The filename should be created with the same character set as with the other tools (example JSZIP).
Desktop (please complete the following information):

Windows 11
Browser: Chrome Version 109.0.5414.75 (Official Build) (32-bit)

Hello. This sounds like the previously reported problem in #23 . Please read the conversation there and if necessary, reopen that issue. Basically, it may be solved by using the Unicode Path attribute, or not… we're not sure because nobody has tested it so far, as nobody felt like it was worth trying. What we do know for sure, is that it won't be solved by using "the same character set" as the host OS, because we actually don't know what it is (Windows can use a variety of encodings and doesn't tell JavaScript which one it is).

The EFS bit added in the latest release may have solved your issue with less hassle than the Unicode extra field. Can you confirm ?


Adds the ability to run aribtrary sql queries.

Queries are run on the Repo class. You can choose between getting back the PG::Result or having crecto cast the result set from PG as an object type.

The build is failing because crystal-pg just updated to version 0.12.0 which includes support for crystal-db. This resulted in errors within micrate and now the database can't be migrated during testing.
@fridgerator Maybe we should remove the reliance on micrate for development?

👍
I've been anticipating this pg release, it seems it is now an adapter for crystal-db.  This will require some changes in Crecto postgres adapter.  Talking with @bcardiff in gitter, they will be updating the documentation in the next few days.
As far as removing micrate, would you suggest that setting up the database in the test env is fully dependent on the user?  I'm ok with that, I just need a way to set up the database in travis ci for testing github commits.
One more thing, I have some association (belongs_to, has_many) functionality working but it required some small changes.  Biggest one being the model will now just inherits from crecto model rather than include schema and extend changeset.  This was the only way I could get associations working how I wanted, was to use a base class.  Here is the branch, the readme is updated with the changes and associations.

@fridgerator let me code something up that removes the dependency on micrate in a separate PR. Also, I'm in gitter / irc #crystal-lang if you need to reach me.

Ok great.
FYI I pushed a commit to master that adds a dependency on crystal-pg version 0.11.0 for now, until 0.12.0 can be used.

@fridgerator, aside from micrate itself is there something else that will block you from moving to crystal-db?

@bcardiff I just need to update our adapter to use crystal-db now.


Adv qml demo

Title: Adversarial Attacks on Quantum Machine Learning
Summary: Tutorial on attacks and defenses in Quantum machine learning with hands-on example.
Relevant references: 'A comparative analysis of adversarial robustness for quantum and classical machine learning' by M.Wendlinger, K.Tscharke, P.Debus
Possible Drawbacks:
Related GitHub Issues:

If you are writing a demonstration, please answer these questions to facilitate the marketing process.

GOALS — Why are we working on this now?

Show a PL implementation of a recent paper, introduce emerging topic of quantum adversarial machine learning

AUDIENCE — Who is this for?

Everyone interested in Quantum machine learning, especially those with focus on security

KEYWORDS — What words should be included in the marketing post?

Quantum machine learning, adversarial attacks, QAML, ..

Which of the following types of documentation is most similar to your file?
(more details here)

[ ] Tutorial
[x] Demo
[ ] How-to

@ikurecic

Also, for internal tracking: [sc-65330]
I'll assign you a technical reviewer soon, thanks!

I am currently using a local .h5 file (which obviously doesn't work as it is not present in the pennylane dir structure), should I include this in the _static/ folder to load the data for the classifier in the tutorial? is there some folder which is more suitable? once the data is hosted on the pennylane datasets this issue resolves itself

I am currently using a local .h5 file (which obviously doesn't work as it is not present in the pennylane dir structure), should I include this in the _static/ folder to load the data for the classifier in the tutorial? is there some folder which is more suitable? once the data is hosted on the pennylane datasets this issue resolves itself

Great point! Yup, let's add the dataset in the _static folder and access it with qml.data.Dataset.open This way we can preview what the final demo will look like. We'll consider merging this PR to  be blocked until we upload the dataset. Once the dataset is uploaded, we can update this PR and merge it.

I am currently using a local .h5 file (which obviously doesn't work as it is not present in the pennylane dir structure), should I include this in the _static/ folder to load the data for the classifier in the tutorial? is there some folder which is more suitable? once the data is hosted on the pennylane datasets this issue resolves itself

Great point! Yup, let's add the dataset in the _static folder and access it with qml.data.Dataset.open This way we can preview what the final demo will look like. We'll consider merging this PR to be blocked until we upload the dataset. Once the dataset is uploaded, we can update this PR and merge it.

Hi @mwendlinger , I'm not sure if you saw Diego's response from last week, so I'm tagging you here. ☺

I am currently using a local .h5 file (which obviously doesn't work as it is not present in the pennylane dir structure), should I include this in the _static/ folder to load the data for the classifier in the tutorial? is there some folder which is more suitable? once the data is hosted on the pennylane datasets this issue resolves itself

Great point! Yup, let's add the dataset in the _static folder and access it with qml.data.Dataset.open This way we can preview what the final demo will look like. We'll consider merging this PR to be blocked until we upload the dataset. Once the dataset is uploaded, we can update this PR and merge it.

Hi @mwendlinger , I'm not sure if you saw Diego's response from last week, so I'm tagging you here. ☺

Yes, that totally makes sense, I already added the dataset file into the directory per my last commit, so for testing purposes, this should work 😄

can we adjust the order of the authors

Looking into this!

what is a suitable alternative for the latex blocks that are not rendered correctly? should I include images of the equations?

We should be able to get this to display correctly. I'll leave suggestions in comments, but I think :math: and .. math:: directives should help here.

I guess there is some trouble parsing the last About the authors section as some code is displayed in the demo. How can I fix this?

We can try simply removing this and the authors should render correctly based on the .metadata.json file

can we adjust the order of the authors

There is an update in progress that changes how the author metadata is handled. As soon as it's merged (1-2 weeks), the authors should be displayed in the same order as the .metadata.json file and be in the correct order :+1:

perfect, thank you!

thank you very much for the review, these are great points! I modified the demo file; now the references, math blocks and links should work. I also included the docstring and a short comment on PGD. I will re-iterate over the file in the next days but it seems quite nice so far 😄

Hi @ikurecic,
I modified the demo and included your suggestions, thanks for the feedback! If there is anything missing, feel free t ping me (as far as I can see, the only two things left are the demo date and the dataset loading - if we want to change this to the actual dataset hub).

Hi @ikurecic, I modified the demo and included your suggestions, thanks for the feedback! If there is anything missing, feel free t ping me (as far as I can see, the only two things left are the demo date and the dataset loading - if we want to change this to the actual dataset hub).

Thanks a lot for the note, @mwendlinger !
@DSGuala , could you set up the dataset access here once its ready and share your approval on the pull request once that happens?
The final details (date, checks, second approval and the merging process) can be left to me.


python3.10-openapi-core-0.14.2.drv' failed with exit code 1;

error: builder for '/nix/store/vk8ssxaxsa0w424zy7l5lsha3hj2lflp-python3.10-openapi-core-0.14.2.drv' failed with exit code 1;
last 10 log lines:
>   File "", line 688, in _load_unlocked
>   File "", line 883, in exec_module
>   File "", line 241, in _call_with_frames_removed
>   File "/nix/store/w3gw9b66a9cigv9612dn51avqd1y86w6-python3.10-openapi-core-0.14.2/lib/python3.10/site-packages/openapi_core/init.py", line 3, in
>     from openapi_core.shortcuts import (
>   File "/nix/store/w3gw9b66a9cigv9612dn51avqd1y86w6-python3.10-openapi-core-0.14.2/lib/python3.10/site-packages/openapi_core/shortcuts.py", line 3, in
>     from openapi_core.spec.shortcuts import create_spec
>   File "/nix/store/w3gw9b66a9cigv9612dn51avqd1y86w6-python3.10-openapi-core-0.14.2/lib/python3.10/site-packages/openapi_core/spec/shortcuts.py", line 3, in
>     from openapi_spec_validator import (
> ImportError: cannot import name 'default_handlers' from 'openapi_spec_validator' (/nix/store/qlirpzf1vnalp6jnl2xgl4m7vir5dfa7-python3.10-openapi-spec-validator-0.5.1/lib/python3.10/site-packages/openapi_spec_validator/init.py)
For full logs, run 'nix log /nix/store/vk8ssxaxsa0w424zy7l5lsha3hj2lflp-python3.10-openapi-core-0.14.2.drv'.
error: 1 dependencies of derivation '/nix/store/097xfzd04xk41qij6za3973h1yzvqm9f-python3.10-jupyterlab_server-2.15.2.drv' failed to build
error: 1 dependencies of derivation '/nix/store/0gcsslr4jdgkw2yfwkw6sv7lspr88058-python3.10-jupyterlab_server-2.15.2.drv' failed to build
error: 1 dependencies of derivation '/nix/store/fk5sxrhlsr8mxkcj00lh7myhjgdfzk35-python3.10-jupyterlab-3.4.7.drv' failed to build
error: 1 dependencies of derivation '/nix/store/bd9i6nr3ld7lfkyhmb1rh5j31j5jppwf-system-applications.drv' failed to build
error: 1 dependencies of derivation '/nix/store/wwyl8cpvn7pwbmcg1292kcwk8p57yq4r-darwin-system-22.11.20221001.b746456+darwin4.02d2551.drv' failed to build

1   │ Sourcing python-remove-tests-dir-hook
2   │ Sourcing python-catch-conflicts-hook.sh
3   │ Sourcing python-remove-bin-bytecode-hook.sh
4   │ Sourcing setuptools-build-hook
5   │ Using setuptoolsBuildPhase
6   │ Using setuptoolsShellHook
7   │ Sourcing pip-install-hook
8   │ Using pipInstallPhase
9   │ Sourcing python-imports-check-hook.sh
10   │ Using pythonImportsCheckPhase
11   │ Sourcing python-namespaces-hook
12   │ Sourcing python-catch-conflicts-hook.sh
13   │ Sourcing setuptools-check-hook
14   │ Using setuptoolsCheckPhase
15   │ Sourcing pytest-check-hook
16   │ Using pytestCheckPhase
17   │ Removing setuptoolsCheckPhase
18   │ @nix { "action": "setPhase", "phase": "unpackPhase" }
19   │ unpacking sources
20   │ unpacking source archive /nix/store/6yap2js5qpxqb896j8pg5r8rfm5zr6xp-source
21   │ source root is source
22   │ setting SOURCE_DATE_EPOCH to timestamp 315619200 of file source/tests/unit/validation/test_response_shortcuts.py
23   │ @nix { "action": "setPhase", "phase": "patchPhase" }
24   │ patching sources
25   │ @nix { "action": "setPhase", "phase": "configurePhase" }
26   │ configuring
27   │ no configure script, doing nothing
28   │ @nix { "action": "setPhase", "phase": "buildPhase" }
29   │ building
30   │ Executing setuptoolsBuildPhase
31   │ /nix/store/2sm4md8fqn3f189zvhz3rjpdlkbdy1sa-python3.10-setuptools-65.3.0/lib/python3.10/site-packages/setuptools/dist.py:771: UserWarning: Usage of
│ dash-separated 'long-description-content-type' will not be supported in future versions. Please use the underscore name 'long_description_content_ty
│ pe' instead
32   │   warnings.warn(
33   │ /nix/store/2sm4md8fqn3f189zvhz3rjpdlkbdy1sa-python3.10-setuptools-65.3.0/lib/python3.10/site-packages/setuptools/distutils/dist.py:262: UserWarning
│ : Unknown distribution option: 'setup_cfg'
34   │   warnings.warn(msg)
35   │ running bdist_wheel
36   │ running build
37   │ running build_py
38   │ creating build
39   │ creating build/lib
40   │ creating build/lib/openapi_core
41   │ copying openapi_core/compat.py -> build/lib/openapi_core
42   │ copying openapi_core/shortcuts.py -> build/lib/openapi_core
43   │ copying openapi_core/init.py -> build/lib/openapi_core
44   │ copying openapi_core/types.py -> build/lib/openapi_core
45   │ copying openapi_core/exceptions.py -> build/lib/openapi_core
46   │ creating build/lib/openapi_core/security
47   │ copying openapi_core/security/init.py -> build/lib/openapi_core/security
48   │ copying openapi_core/security/factories.py -> build/lib/openapi_core/security
49   │ copying openapi_core/security/providers.py -> build/lib/openapi_core/security
50   │ copying openapi_core/security/exceptions.py -> build/lib/openapi_core/security
51   │ creating build/lib/openapi_core/spec
52   │ copying openapi_core/spec/accessors.py -> build/lib/openapi_core/spec
53   │ copying openapi_core/spec/paths.py -> build/lib/openapi_core/spec
54   │ copying openapi_core/spec/shortcuts.py -> build/lib/openapi_core/spec
55   │ copying openapi_core/spec/init.py -> build/lib/openapi_core/spec
56   │ creating build/lib/openapi_core/templating
57   │ copying openapi_core/templating/util.py -> build/lib/openapi_core/templating
58   │ copying openapi_core/templating/init.py -> build/lib/openapi_core/templating
59   │ copying openapi_core/templating/datatypes.py -> build/lib/openapi_core/templating
60   │ creating build/lib/openapi_core/contrib
61   │ copying openapi_core/contrib/init.py -> build/lib/openapi_core/contrib
62   │ creating build/lib/openapi_core/extensions
63   │ copying openapi_core/extensions/init.py -> build/lib/openapi_core/extensions
64   │ creating build/lib/openapi_core/testing
65   │ copying openapi_core/testing/responses.py -> build/lib/openapi_core/testing
66   │ copying openapi_core/testing/init.py -> build/lib/openapi_core/testing
67   │ copying openapi_core/testing/factories.py -> build/lib/openapi_core/testing
68   │ copying openapi_core/testing/datatypes.py -> build/lib/openapi_core/testing
69   │ copying openapi_core/testing/requests.py -> build/lib/openapi_core/testing
70   │ copying openapi_core/testing/mock.py -> build/lib/openapi_core/testing
71   │ creating build/lib/openapi_core/schema
72   │ copying openapi_core/schema/specs.py -> build/lib/openapi_core/schema
73   │ copying openapi_core/schema/init.py -> build/lib/openapi_core/schema
74   │ copying openapi_core/schema/servers.py -> build/lib/openapi_core/schema
75   │ copying openapi_core/schema/schemas.py -> build/lib/openapi_core/schema
76   │ copying openapi_core/schema/parameters.py -> build/lib/openapi_core/schema
77   │ creating build/lib/openapi_core/deserializing
78   │ copying openapi_core/deserializing/init.py -> build/lib/openapi_core/deserializing
79   │ copying openapi_core/deserializing/exceptions.py -> build/lib/openapi_core/deserializing
80   │ creating build/lib/openapi_core/casting
81   │ copying openapi_core/casting/init.py -> build/lib/openapi_core/casting
82   │ creating build/lib/openapi_core/validation
83   │ copying openapi_core/validation/validators.py -> build/lib/openapi_core/validation
84   │ copying openapi_core/validation/init.py -> build/lib/openapi_core/validation
85   │ copying openapi_core/validation/datatypes.py -> build/lib/openapi_core/validation
86   │ copying openapi_core/validation/exceptions.py -> build/lib/openapi_core/validation
87   │ copying openapi_core/validation/processors.py -> build/lib/openapi_core/validation
88   │ copying openapi_core/validation/decorators.py -> build/lib/openapi_core/validation
89   │ creating build/lib/openapi_core/unmarshalling
90   │ copying openapi_core/unmarshalling/init.py -> build/lib/openapi_core/unmarshalling
91   │ creating build/lib/openapi_core/templating/responses
92   │ copying openapi_core/templating/responses/finders.py -> build/lib/openapi_core/templating/responses
93   │ copying openapi_core/templating/responses/init.py -> build/lib/openapi_core/templating/responses
94   │ copying openapi_core/templating/responses/exceptions.py -> build/lib/openapi_core/templating/responses
95   │ creating build/lib/openapi_core/templating/paths
96   │ copying openapi_core/templating/paths/finders.py -> build/lib/openapi_core/templating/paths
97   │ copying openapi_core/templating/paths/init.py -> build/lib/openapi_core/templating/paths
98   │ copying openapi_core/templating/paths/exceptions.py -> build/lib/openapi_core/templating/paths
99   │ creating build/lib/openapi_core/templating/media_types
100   │ copying openapi_core/templating/media_types/finders.py -> build/lib/openapi_core/templating/media_types
101   │ copying openapi_core/templating/media_types/init.py -> build/lib/openapi_core/templating/media_types
102   │ copying openapi_core/templating/media_types/exceptions.py -> build/lib/openapi_core/templating/media_types
103   │ creating build/lib/openapi_core/contrib/flask
104   │ copying openapi_core/contrib/flask/responses.py -> build/lib/openapi_core/contrib/flask
105   │ copying openapi_core/contrib/flask/handlers.py -> build/lib/openapi_core/contrib/flask
106   │ copying openapi_core/contrib/flask/init.py -> build/lib/openapi_core/contrib/flask
107   │ copying openapi_core/contrib/flask/providers.py -> build/lib/openapi_core/contrib/flask
108   │ copying openapi_core/contrib/flask/requests.py -> build/lib/openapi_core/contrib/flask
109   │ copying openapi_core/contrib/flask/views.py -> build/lib/openapi_core/contrib/flask
110   │ copying openapi_core/contrib/flask/decorators.py -> build/lib/openapi_core/contrib/flask
111   │ creating build/lib/openapi_core/contrib/requests
112   │ copying openapi_core/contrib/requests/responses.py -> build/lib/openapi_core/contrib/requests
113   │ copying openapi_core/contrib/requests/init.py -> build/lib/openapi_core/contrib/requests
114   │ copying openapi_core/contrib/requests/requests.py -> build/lib/openapi_core/contrib/requests
115   │ creating build/lib/openapi_core/contrib/django
116   │ copying openapi_core/contrib/django/responses.py -> build/lib/openapi_core/contrib/django
117   │ copying openapi_core/contrib/django/compat.py -> build/lib/openapi_core/contrib/django
118   │ copying openapi_core/contrib/django/init.py -> build/lib/openapi_core/contrib/django
119   │ copying openapi_core/contrib/django/backports.py -> build/lib/openapi_core/contrib/django
120   │ copying openapi_core/contrib/django/requests.py -> build/lib/openapi_core/contrib/django
121   │ creating build/lib/openapi_core/contrib/falcon
122   │ copying openapi_core/contrib/falcon/responses.py -> build/lib/openapi_core/contrib/falcon
123   │ copying openapi_core/contrib/falcon/compat.py -> build/lib/openapi_core/contrib/falcon
124   │ copying openapi_core/contrib/falcon/handlers.py -> build/lib/openapi_core/contrib/falcon
125   │ copying openapi_core/contrib/falcon/init.py -> build/lib/openapi_core/contrib/falcon
126   │ copying openapi_core/contrib/falcon/middlewares.py -> build/lib/openapi_core/contrib/falcon
127   │ copying openapi_core/contrib/falcon/requests.py -> build/lib/openapi_core/contrib/falcon
128   │ copying openapi_core/contrib/falcon/views.py -> build/lib/openapi_core/contrib/falcon
129   │ creating build/lib/openapi_core/extensions/models
130   │ copying openapi_core/extensions/models/models.py -> build/lib/openapi_core/extensions/models
131   │ copying openapi_core/extensions/models/init.py -> build/lib/openapi_core/extensions/models
132   │ copying openapi_core/extensions/models/factories.py -> build/lib/openapi_core/extensions/models
133   │ creating build/lib/openapi_core/deserializing/parameters
134   │ copying openapi_core/deserializing/parameters/deserializers.py -> build/lib/openapi_core/deserializing/parameters
135   │ copying openapi_core/deserializing/parameters/init.py -> build/lib/openapi_core/deserializing/parameters
136   │ copying openapi_core/deserializing/parameters/factories.py -> build/lib/openapi_core/deserializing/parameters
137   │ copying openapi_core/deserializing/parameters/exceptions.py -> build/lib/openapi_core/deserializing/parameters
138   │ creating build/lib/openapi_core/deserializing/media_types
139   │ copying openapi_core/deserializing/media_types/deserializers.py -> build/lib/openapi_core/deserializing/media_types
140   │ copying openapi_core/deserializing/media_types/util.py -> build/lib/openapi_core/deserializing/media_types
141   │ copying openapi_core/deserializing/media_types/init.py -> build/lib/openapi_core/deserializing/media_types
142   │ copying openapi_core/deserializing/media_types/factories.py -> build/lib/openapi_core/deserializing/media_types
143   │ creating build/lib/openapi_core/casting/schemas
144   │ copying openapi_core/casting/schemas/util.py -> build/lib/openapi_core/casting/schemas
145   │ copying openapi_core/casting/schemas/init.py -> build/lib/openapi_core/casting/schemas
146   │ copying openapi_core/casting/schemas/factories.py -> build/lib/openapi_core/casting/schemas
147   │ copying openapi_core/casting/schemas/exceptions.py -> build/lib/openapi_core/casting/schemas
148   │ copying openapi_core/casting/schemas/casters.py -> build/lib/openapi_core/casting/schemas
149   │ creating build/lib/openapi_core/validation/response
150   │ copying openapi_core/validation/response/shortcuts.py -> build/lib/openapi_core/validation/response
151   │ copying openapi_core/validation/response/validators.py -> build/lib/openapi_core/validation/response
152   │ copying openapi_core/validation/response/init.py -> build/lib/openapi_core/validation/response
153   │ copying openapi_core/validation/response/datatypes.py -> build/lib/openapi_core/validation/response
154   │ creating build/lib/openapi_core/validation/request
155   │ copying openapi_core/validation/request/shortcuts.py -> build/lib/openapi_core/validation/request
156   │ copying openapi_core/validation/request/validators.py -> build/lib/openapi_core/validation/request
157   │ copying openapi_core/validation/request/init.py -> build/lib/openapi_core/validation/request
158   │ copying openapi_core/validation/request/datatypes.py -> build/lib/openapi_core/validation/request
159   │ creating build/lib/openapi_core/unmarshalling/schemas
160   │ copying openapi_core/unmarshalling/schemas/enums.py -> build/lib/openapi_core/unmarshalling/schemas
161   │ copying openapi_core/unmarshalling/schemas/formatters.py -> build/lib/openapi_core/unmarshalling/schemas
162   │ copying openapi_core/unmarshalling/schemas/unmarshallers.py -> build/lib/openapi_core/unmarshalling/schemas
163   │ copying openapi_core/unmarshalling/schemas/util.py -> build/lib/openapi_core/unmarshalling/schemas
164   │ copying openapi_core/unmarshalling/schemas/init.py -> build/lib/openapi_core/unmarshalling/schemas
165   │ copying openapi_core/unmarshalling/schemas/factories.py -> build/lib/openapi_core/unmarshalling/schemas
166   │ copying openapi_core/unmarshalling/schemas/exceptions.py -> build/lib/openapi_core/unmarshalling/schemas
167   │ running egg_info
168   │ creating openapi_core.egg-info
169   │ writing openapi_core.egg-info/PKG-INFO
170   │ writing dependency_links to openapi_core.egg-info/dependency_links.txt
171   │ writing requirements to openapi_core.egg-info/requires.txt
172   │ writing top-level names to openapi_core.egg-info/top_level.txt
173   │ writing manifest file 'openapi_core.egg-info/SOURCES.txt'
174   │ reading manifest file 'openapi_core.egg-info/SOURCES.txt'
175   │ reading manifest template 'MANIFEST.in'
176   │ adding license file 'LICENSE'
177   │ writing manifest file 'openapi_core.egg-info/SOURCES.txt'
178   │ /nix/store/2sm4md8fqn3f189zvhz3rjpdlkbdy1sa-python3.10-setuptools-65.3.0/lib/python3.10/site-packages/setuptools/command/install.py:34: SetuptoolsDe
│ precationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
179   │   warnings.warn(
180   │ installing to build/bdist.macosx-10.12-x86_64/wheel
181   │ running install
182   │ running install_lib
183   │ creating build/bdist.macosx-10.12-x86_64
184   │ creating build/bdist.macosx-10.12-x86_64/wheel
185   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core
186   │ copying build/lib/openapi_core/compat.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core
187   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/security
188   │ copying build/lib/openapi_core/security/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/security
189   │ copying build/lib/openapi_core/security/factories.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/security
190   │ copying build/lib/openapi_core/security/providers.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/security
191   │ copying build/lib/openapi_core/security/exceptions.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/security
192   │ copying build/lib/openapi_core/shortcuts.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core
193   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/spec
194   │ copying build/lib/openapi_core/spec/accessors.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/spec
195   │ copying build/lib/openapi_core/spec/paths.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/spec
196   │ copying build/lib/openapi_core/spec/shortcuts.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/spec
197   │ copying build/lib/openapi_core/spec/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/spec
198   │ copying build/lib/openapi_core/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core
199   │ copying build/lib/openapi_core/types.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core
200   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/templating
201   │ copying build/lib/openapi_core/templating/util.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/templating
202   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/templating/responses
203   │ copying build/lib/openapi_core/templating/responses/finders.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/templating/responses
204   │ copying build/lib/openapi_core/templating/responses/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/templating/responses
205   │ copying build/lib/openapi_core/templating/responses/exceptions.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/templating/responses
206   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/templating/paths
207   │ copying build/lib/openapi_core/templating/paths/finders.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/templating/paths
208   │ copying build/lib/openapi_core/templating/paths/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/templating/paths
209   │ copying build/lib/openapi_core/templating/paths/exceptions.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/templating/paths
210   │ copying build/lib/openapi_core/templating/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/templating
211   │ copying build/lib/openapi_core/templating/datatypes.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/templating
212   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/templating/media_types
213   │ copying build/lib/openapi_core/templating/media_types/finders.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/templating/media_types
214   │ copying build/lib/openapi_core/templating/media_types/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/templating/media_types
215   │ copying build/lib/openapi_core/templating/media_types/exceptions.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/templating/media_types
216   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib
217   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/flask
218   │ copying build/lib/openapi_core/contrib/flask/responses.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/flask
219   │ copying build/lib/openapi_core/contrib/flask/handlers.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/flask
220   │ copying build/lib/openapi_core/contrib/flask/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/flask
221   │ copying build/lib/openapi_core/contrib/flask/providers.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/flask
222   │ copying build/lib/openapi_core/contrib/flask/requests.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/flask
223   │ copying build/lib/openapi_core/contrib/flask/views.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/flask
224   │ copying build/lib/openapi_core/contrib/flask/decorators.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/flask
225   │ copying build/lib/openapi_core/contrib/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib
226   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/requests
227   │ copying build/lib/openapi_core/contrib/requests/responses.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/requests
228   │ copying build/lib/openapi_core/contrib/requests/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/requests
229   │ copying build/lib/openapi_core/contrib/requests/requests.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/requests
230   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/django
231   │ copying build/lib/openapi_core/contrib/django/responses.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/django
232   │ copying build/lib/openapi_core/contrib/django/compat.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/django
233   │ copying build/lib/openapi_core/contrib/django/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/django
234   │ copying build/lib/openapi_core/contrib/django/backports.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/django
235   │ copying build/lib/openapi_core/contrib/django/requests.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/django
236   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/falcon
237   │ copying build/lib/openapi_core/contrib/falcon/responses.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/falcon
238   │ copying build/lib/openapi_core/contrib/falcon/compat.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/falcon
239   │ copying build/lib/openapi_core/contrib/falcon/handlers.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/falcon
240   │ copying build/lib/openapi_core/contrib/falcon/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/falcon
241   │ copying build/lib/openapi_core/contrib/falcon/middlewares.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/falcon
242   │ copying build/lib/openapi_core/contrib/falcon/requests.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/falcon
243   │ copying build/lib/openapi_core/contrib/falcon/views.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/contrib/falcon
244   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/extensions
245   │ copying build/lib/openapi_core/extensions/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/extensions
246   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/extensions/models
247   │ copying build/lib/openapi_core/extensions/models/models.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/extensions/models
248   │ copying build/lib/openapi_core/extensions/models/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/extensions/models
249   │ copying build/lib/openapi_core/extensions/models/factories.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/extensions/models
250   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/testing
251   │ copying build/lib/openapi_core/testing/responses.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/testing
252   │ copying build/lib/openapi_core/testing/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/testing
253   │ copying build/lib/openapi_core/testing/factories.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/testing
254   │ copying build/lib/openapi_core/testing/datatypes.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/testing
255   │ copying build/lib/openapi_core/testing/requests.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/testing
256   │ copying build/lib/openapi_core/testing/mock.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/testing
257   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/schema
258   │ copying build/lib/openapi_core/schema/specs.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/schema
259   │ copying build/lib/openapi_core/schema/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/schema
260   │ copying build/lib/openapi_core/schema/servers.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/schema
261   │ copying build/lib/openapi_core/schema/schemas.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/schema
262   │ copying build/lib/openapi_core/schema/parameters.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/schema
263   │ copying build/lib/openapi_core/exceptions.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core
264   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/deserializing
265   │ copying build/lib/openapi_core/deserializing/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/deserializing
266   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/deserializing/parameters
267   │ copying build/lib/openapi_core/deserializing/parameters/deserializers.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/deserializing/paramet
│ ers
268   │ copying build/lib/openapi_core/deserializing/parameters/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/deserializing/parameters
269   │ copying build/lib/openapi_core/deserializing/parameters/factories.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/deserializing/parameters
270   │ copying build/lib/openapi_core/deserializing/parameters/exceptions.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/deserializing/parameters
271   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/deserializing/media_types
272   │ copying build/lib/openapi_core/deserializing/media_types/deserializers.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/deserializing/media
│ types
273   │ copying build/lib/openapi_core/deserializing/media_types/util.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/deserializing/media_types
274   │ copying build/lib/openapi_core/deserializing/media_types/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/deserializing/media_types
275   │ copying build/lib/openapi_core/deserializing/media_types/factories.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/deserializing/media_type
│ s
276   │ copying build/lib/openapi_core/deserializing/exceptions.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/deserializing
277   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/casting
278   │ copying build/lib/openapi_core/casting/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/casting
279   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/casting/schemas
280   │ copying build/lib/openapi_core/casting/schemas/util.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/casting/schemas
281   │ copying build/lib/openapi_core/casting/schemas/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/casting/schemas
282   │ copying build/lib/openapi_core/casting/schemas/factories.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/casting/schemas
283   │ copying build/lib/openapi_core/casting/schemas/exceptions.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/casting/schemas
284   │ copying build/lib/openapi_core/casting/schemas/casters.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/casting/schemas
285   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation
286   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation/response
287   │ copying build/lib/openapi_core/validation/response/shortcuts.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation/response
288   │ copying build/lib/openapi_core/validation/response/validators.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation/response
289   │ copying build/lib/openapi_core/validation/response/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation/response
290   │ copying build/lib/openapi_core/validation/response/datatypes.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation/response
291   │ copying build/lib/openapi_core/validation/validators.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation
292   │ copying build/lib/openapi_core/validation/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation
293   │ copying build/lib/openapi_core/validation/datatypes.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation
294   │ copying build/lib/openapi_core/validation/exceptions.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation
295   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation/request
296   │ copying build/lib/openapi_core/validation/request/shortcuts.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation/request
297   │ copying build/lib/openapi_core/validation/request/validators.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation/request
298   │ copying build/lib/openapi_core/validation/request/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation/request
299   │ copying build/lib/openapi_core/validation/request/datatypes.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation/request
300   │ copying build/lib/openapi_core/validation/processors.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation
301   │ copying build/lib/openapi_core/validation/decorators.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/validation
302   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/unmarshalling
303   │ copying build/lib/openapi_core/unmarshalling/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/unmarshalling
304   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core/unmarshalling/schemas
305   │ copying build/lib/openapi_core/unmarshalling/schemas/enums.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/unmarshalling/schemas
306   │ copying build/lib/openapi_core/unmarshalling/schemas/formatters.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/unmarshalling/schemas
307   │ copying build/lib/openapi_core/unmarshalling/schemas/unmarshallers.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/unmarshalling/schemas
308   │ copying build/lib/openapi_core/unmarshalling/schemas/util.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/unmarshalling/schemas
309   │ copying build/lib/openapi_core/unmarshalling/schemas/init.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/unmarshalling/schemas
310   │ copying build/lib/openapi_core/unmarshalling/schemas/factories.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/unmarshalling/schemas
311   │ copying build/lib/openapi_core/unmarshalling/schemas/exceptions.py -> build/bdist.macosx-10.12-x86_64/wheel/openapi_core/unmarshalling/schemas
312   │ running install_egg_info
313   │ Copying openapi_core.egg-info to build/bdist.macosx-10.12-x86_64/wheel/openapi_core-0.14.2-py3.10.egg-info
314   │ running install_scripts
315   │ adding license file "LICENSE" (matched pattern "LICEN[CS]E*")
316   │ creating build/bdist.macosx-10.12-x86_64/wheel/openapi_core-0.14.2.dist-info/WHEEL
317   │ creating 'dist/openapi_core-0.14.2-py3-none-any.whl' and adding 'build/bdist.macosx-10.12-x86_64/wheel' to it
318   │ adding 'openapi_core/init.py'
319   │ adding 'openapi_core/compat.py'
320   │ adding 'openapi_core/exceptions.py'
321   │ adding 'openapi_core/shortcuts.py'
322   │ adding 'openapi_core/types.py'
323   │ adding 'openapi_core/casting/init.py'
324   │ adding 'openapi_core/casting/schemas/init.py'
325   │ adding 'openapi_core/casting/schemas/casters.py'
326   │ adding 'openapi_core/casting/schemas/exceptions.py'
327   │ adding 'openapi_core/casting/schemas/factories.py'
328   │ adding 'openapi_core/casting/schemas/util.py'
329   │ adding 'openapi_core/contrib/init.py'
330   │ adding 'openapi_core/contrib/django/init.py'
331   │ adding 'openapi_core/contrib/django/backports.py'
332   │ adding 'openapi_core/contrib/django/compat.py'
333   │ adding 'openapi_core/contrib/django/requests.py'
334   │ adding 'openapi_core/contrib/django/responses.py'
335   │ adding 'openapi_core/contrib/falcon/init.py'
336   │ adding 'openapi_core/contrib/falcon/compat.py'
337   │ adding 'openapi_core/contrib/falcon/handlers.py'
338   │ adding 'openapi_core/contrib/falcon/middlewares.py'
339   │ adding 'openapi_core/contrib/falcon/requests.py'
340   │ adding 'openapi_core/contrib/falcon/responses.py'
341   │ adding 'openapi_core/contrib/falcon/views.py'
342   │ adding 'openapi_core/contrib/flask/init.py'
343   │ adding 'openapi_core/contrib/flask/decorators.py'
344   │ adding 'openapi_core/contrib/flask/handlers.py'
345   │ adding 'openapi_core/contrib/flask/providers.py'
346   │ adding 'openapi_core/contrib/flask/requests.py'
347   │ adding 'openapi_core/contrib/flask/responses.py'
348   │ adding 'openapi_core/contrib/flask/views.py'
349   │ adding 'openapi_core/contrib/requests/init.py'
350   │ adding 'openapi_core/contrib/requests/requests.py'
351   │ adding 'openapi_core/contrib/requests/responses.py'
352   │ adding 'openapi_core/deserializing/init.py'
353   │ adding 'openapi_core/deserializing/exceptions.py'
354   │ adding 'openapi_core/deserializing/media_types/init.py'
355   │ adding 'openapi_core/deserializing/media_types/deserializers.py'
356   │ adding 'openapi_core/deserializing/media_types/factories.py'
357   │ adding 'openapi_core/deserializing/media_types/util.py'
358   │ adding 'openapi_core/deserializing/parameters/init.py'
359   │ adding 'openapi_core/deserializing/parameters/deserializers.py'
360   │ adding 'openapi_core/deserializing/parameters/exceptions.py'
361   │ adding 'openapi_core/deserializing/parameters/factories.py'
362   │ adding 'openapi_core/extensions/init.py'
363   │ adding 'openapi_core/extensions/models/init.py'
364   │ adding 'openapi_core/extensions/models/factories.py'
365   │ adding 'openapi_core/extensions/models/models.py'
366   │ adding 'openapi_core/schema/init.py'
367   │ adding 'openapi_core/schema/parameters.py'
368   │ adding 'openapi_core/schema/schemas.py'
369   │ adding 'openapi_core/schema/servers.py'
370   │ adding 'openapi_core/schema/specs.py'
371   │ adding 'openapi_core/security/init.py'
372   │ adding 'openapi_core/security/exceptions.py'
373   │ adding 'openapi_core/security/factories.py'
374   │ adding 'openapi_core/security/providers.py'
375   │ adding 'openapi_core/spec/init.py'
376   │ adding 'openapi_core/spec/accessors.py'
377   │ adding 'openapi_core/spec/paths.py'
378   │ adding 'openapi_core/spec/shortcuts.py'
379   │ adding 'openapi_core/templating/init.py'
380   │ adding 'openapi_core/templating/datatypes.py'
381   │ adding 'openapi_core/templating/util.py'
382   │ adding 'openapi_core/templating/media_types/init.py'
383   │ adding 'openapi_core/templating/media_types/exceptions.py'
384   │ adding 'openapi_core/templating/media_types/finders.py'
385   │ adding 'openapi_core/templating/paths/init.py'
386   │ adding 'openapi_core/templating/paths/exceptions.py'
387   │ adding 'openapi_core/templating/paths/finders.py'
388   │ adding 'openapi_core/templating/responses/init.py'
389   │ adding 'openapi_core/templating/responses/exceptions.py'
390   │ adding 'openapi_core/templating/responses/finders.py'
391   │ adding 'openapi_core/testing/init.py'
392   │ adding 'openapi_core/testing/datatypes.py'
393   │ adding 'openapi_core/testing/factories.py'
394   │ adding 'openapi_core/testing/mock.py'
395   │ adding 'openapi_core/testing/requests.py'
396   │ adding 'openapi_core/testing/responses.py'
397   │ adding 'openapi_core/unmarshalling/init.py'
398   │ adding 'openapi_core/unmarshalling/schemas/init.py'
399   │ adding 'openapi_core/unmarshalling/schemas/enums.py'
400   │ adding 'openapi_core/unmarshalling/schemas/exceptions.py'
401   │ adding 'openapi_core/unmarshalling/schemas/factories.py'
402   │ adding 'openapi_core/unmarshalling/schemas/formatters.py'
403   │ adding 'openapi_core/unmarshalling/schemas/unmarshallers.py'
404   │ adding 'openapi_core/unmarshalling/schemas/util.py'
405   │ adding 'openapi_core/validation/init.py'
406   │ adding 'openapi_core/validation/datatypes.py'
407   │ adding 'openapi_core/validation/decorators.py'
408   │ adding 'openapi_core/validation/exceptions.py'
409   │ adding 'openapi_core/validation/processors.py'
410   │ adding 'openapi_core/validation/validators.py'
411   │ adding 'openapi_core/validation/request/init.py'
412   │ adding 'openapi_core/validation/request/datatypes.py'
413   │ adding 'openapi_core/validation/request/shortcuts.py'
414   │ adding 'openapi_core/validation/request/validators.py'
415   │ adding 'openapi_core/validation/response/init.py'
416   │ adding 'openapi_core/validation/response/datatypes.py'
417   │ adding 'openapi_core/validation/response/shortcuts.py'
418   │ adding 'openapi_core/validation/response/validators.py'
419   │ adding 'openapi_core-0.14.2.dist-info/LICENSE'
420   │ adding 'openapi_core-0.14.2.dist-info/METADATA'
421   │ adding 'openapi_core-0.14.2.dist-info/WHEEL'
422   │ adding 'openapi_core-0.14.2.dist-info/top_level.txt'
423   │ adding 'openapi_core-0.14.2.dist-info/RECORD'
424   │ removing build/bdist.macosx-10.12-x86_64/wheel
425   │ Finished executing setuptoolsBuildPhase
426   │ @nix { "action": "setPhase", "phase": "installPhase" }
427   │ installing
428   │ Executing pipInstallPhase
429   │ /private/tmp/nix-build-python3.10-openapi-core-0.14.2.drv-0/source/dist /private/tmp/nix-build-python3.10-openapi-core-0.14.2.drv-0/source
430   │ Processing ./openapi_core-0.14.2-py3-none-any.whl
431   │ Requirement already satisfied: attrs in /nix/store/zfgk1301rchdyb3slvb1pmh370wq1kc3-python3.10-attrs-22.1.0/lib/python3.10/site-packages (from opena
│ pi-core==0.14.2) (22.1.0)
432   │ Requirement already satisfied: lazy-object-proxy in /nix/store/dsprp4d370v3d8kvwqi98k11khrp3x5l-python3.10-lazy-object-proxy-1.7.1/lib/python3.10/si
│ te-packages (from openapi-core==0.14.2) (1.7.1)
433   │ Requirement already satisfied: more-itertools in /nix/store/fpqq72mlbixbr84kf1gam7pmzrhwm981-python3.10-more-itertools-8.14.0/lib/python3.10/site-pa
│ ckages (from openapi-core==0.14.2) (8.14.0)
434   │ Requirement already satisfied: six in /nix/store/w6h99vi4z7klrgg6q005wniaz6q87hhi-python3.10-six-1.16.0/lib/python3.10/site-packages (from openapi-c
│ ore==0.14.2) (1.16.0)
435   │ Requirement already satisfied: dictpath in /nix/store/ybpgwvkszcdpn0b9456qahnggvg5f9vj-python3.10-dictpath-0.1.3/lib/python3.10/site-packages (from
│ openapi-core==0.14.2) (0.1.3)
436   │ Requirement already satisfied: parse in /nix/store/38fygmfdv9m56kc7cgbp1i2wxwra5y6r-python3.10-parse-1.19.0/lib/python3.10/site-packages (from opena
│ pi-core==0.14.2) (1.19.0)
437   │ Requirement already satisfied: werkzeug in /nix/store/06ww9iadkgzmvilpzaya1z7j47jjghqn-python3.10-werkzeug-2.2.2/lib/python3.10/site-packages (from
│ openapi-core==0.14.2) (2.2.2)
438   │ Requirement already satisfied: openapi-schema-validator in /nix/store/a9rhbn3j4y0sgxch4nr70pip8a79d23l-python3.10-openapi-schema-validator-0.3.4/lib
│ /python3.10/site-packages (from openapi-core==0.14.2) (0.3.4)
439   │ Requirement already satisfied: isodate in /nix/store/yvvbblvqq20ssr7rdqkk73wc5imf0jd5-python3.10-isodate-0.6.1/lib/python3.10/site-packages (from op
│ enapi-core==0.14.2) (0.6.1)
440   │ Requirement already satisfied: openapi-spec-validator in /nix/store/qlirpzf1vnalp6jnl2xgl4m7vir5dfa7-python3.10-openapi-spec-validator-0.5.1/lib/pyt
│ hon3.10/site-packages (from openapi-core==0.14.2) (0.5.1)
441   │ Requirement already satisfied: jsonschema<5.0.0,>=4.0.0 in /nix/store/ccfza3ay54czd3yrrls1c3ri906vpkxa-python3.10-jsonschema-4.16.0/lib/python3.10/s
│ ite-packages (from openapi-schema-validator->openapi-core==0.14.2) (4.16.0)
442   │ Requirement already satisfied: importlib-resources<6.0.0,>=5.8.0 in /nix/store/psxi9glwrrywkmdmlq7cj0ra4hnm6klc-python3.10-importlib-resources-5.9.0
│ /lib/python3.10/site-packages (from openapi-spec-validator->openapi-core==0.14.2) (5.9.0)
443   │ Requirement already satisfied: jsonschema-spec<0.2.0,>=0.1.1 in /nix/store/2ypsfd6afj7i2rcnajh6f75d8ybjq2ab-python3.10-jsonschema-spec-0.1.2/lib/pyt
│ hon3.10/site-packages (from openapi-spec-validator->openapi-core==0.14.2) (0.1.2)
444   │ Requirement already satisfied: PyYAML>=5.1 in /nix/store/i7ffwnp48zz0jwbj018my91lxqid8mfr-python3.10-pyyaml-6.0/lib/python3.10/site-packages (from o
│ penapi-spec-validator->openapi-core==0.14.2) (6.0)
445   │ Requirement already satisfied: MarkupSafe>=2.1.1 in /nix/store/xkaqc0fzql1mw61sszkfrmlay18cg15b-python3.10-markupsafe-2.1.1/lib/python3.10/site-pack
│ ages (from werkzeug->openapi-core==0.14.2) (2.1.1)
446   │ Requirement already satisfied: pyrsistent!=0.17.0,!=0.17.1,!=0.17.2,>=0.14.0 in /nix/store/xyknhzxm76703jiwqac32xm8afvk4zjf-python3.10-pyrsistent-0.
│ 18.1/lib/python3.10/site-packages (from jsonschema<5.0.0,>=4.0.0->openapi-schema-validator->openapi-core==0.14.2) (0.18.1)
447   │ Requirement already satisfied: typing-extensions<5.0.0,>=4.3.0 in /nix/store/1bka3mkmwjmjmghwps4lca966sqbjwl1-python3.10-typing-extensions-4.3.0/lib
│ /python3.10/site-packages (from jsonschema-spec<0.2.0,>=0.1.1->openapi-spec-validator->openapi-core==0.14.2) (4.3.0)
448   │ Requirement already satisfied: pathable<0.5.0,>=0.4.1 in /nix/store/ii7xi7pqq5kdr6f7fzrii4v1dyrasfar-python3.10-pathable-0.4.3/lib/python3.10/site-p
│ ackages (from jsonschema-spec<0.2.0,>=0.1.1->openapi-spec-validator->openapi-core==0.14.2) (0.4.3)
449   │ Installing collected packages: openapi-core
450   │ Successfully installed openapi-core-0.14.2
451   │ /private/tmp/nix-build-python3.10-openapi-core-0.14.2.drv-0/source
452   │ Finished executing pipInstallPhase
453   │ @nix { "action": "setPhase", "phase": "pythonOutputDistPhase" }
454   │ pythonOutputDistPhase
455   │ Executing pythonOutputDistPhase
456   │ Finished executing pythonOutputDistPhase
457   │ @nix { "action": "setPhase", "phase": "fixupPhase" }
458   │ post-installation fixup
459   │ strip is /nix/store/i8w09x9nmibzsi4mahcwns844x0k2h5g-cctools-binutils-darwin-949.0.1/bin/strip
460   │ stripping (with command strip and flags -S) in  /nix/store/w3gw9b66a9cigv9612dn51avqd1y86w6-python3.10-openapi-core-0.14.2/lib
461   │ patching script interpreter paths in /nix/store/w3gw9b66a9cigv9612dn51avqd1y86w6-python3.10-openapi-core-0.14.2
462   │ strip is /nix/store/i8w09x9nmibzsi4mahcwns844x0k2h5g-cctools-binutils-darwin-949.0.1/bin/strip
463   │ patching script interpreter paths in /nix/store/1kd1z7yc06gzfsjzgsq7r4a52f72wx2y-python3.10-openapi-core-0.14.2-dist
464   │ Executing pythonRemoveTestsDir
465   │ Finished executing pythonRemoveTestsDir
466   │ @nix { "action": "setPhase", "phase": "installCheckPhase" }
467   │ running install tests
468   │ no Makefile or custom installCheckPhase, doing nothing
469   │ @nix { "action": "setPhase", "phase": "pythonCatchConflictsPhase" }
470   │ pythonCatchConflictsPhase
471   │ @nix { "action": "setPhase", "phase": "pythonRemoveBinBytecodePhase" }
472   │ pythonRemoveBinBytecodePhase
473   │ @nix { "action": "setPhase", "phase": "pythonImportsCheckPhase" }
474   │ pythonImportsCheckPhase
475   │ Executing pythonImportsCheckPhase
476   │ Check whether the following modules can be imported: openapi_core openapi_core.validation.request.validators openapi_core.validation.response.valida
│ tors
477   │ Traceback (most recent call last):
478   │   File "", line 1, in
479   │   File "", line 1, in
480   │   File "/nix/store/xai4vx954n9iwf6cyahxb3nxa3ld476p-python3-3.10.7/lib/python3.10/importlib/init.py", line 126, in import_module
481   │     return _bootstrap._gcd_import(name[level:], package, level)
482   │   File "", line 1050, in _gcd_import
483   │   File "", line 1027, in _find_and_load
484   │   File "", line 1006, in _find_and_load_unlocked
485   │   File "", line 688, in _load_unlocked
486   │   File "", line 883, in exec_module
487   │   File "", line 241, in _call_with_frames_removed
488   │   File "/nix/store/w3gw9b66a9cigv9612dn51avqd1y86w6-python3.10-openapi-core-0.14.2/lib/python3.10/site-packages/openapi_core/init.py", line 3, i
│ n
489   │     from openapi_core.shortcuts import (
490   │   File "/nix/store/w3gw9b66a9cigv9612dn51avqd1y86w6-python3.10-openapi-core-0.14.2/lib/python3.10/site-packages/openapi_core/shortcuts.py", line 3,
│ in
491   │     from openapi_core.spec.shortcuts import create_spec
492   │   File "/nix/store/w3gw9b66a9cigv9612dn51avqd1y86w6-python3.10-openapi-core-0.14.2/lib/python3.10/site-packages/openapi_core/spec/shortcuts.py", lin
│ e 3, in
493   │     from openapi_spec_validator import (
494   │ ImportError: cannot import name 'default_handlers' from 'openapi_spec_validator' (/nix/store/qlirpzf1vnalp6jnl2xgl4m7vir5dfa7-python3.10-openapi-spe
│ c-validator-0.5.1/lib/python3.10/site-packages/openapi_spec_validator/init.py)

Can you list the steps needed to reproduce this error?

Seeing that it has been fixed for a week, it looks like you went on vacation, haha Besides this, tensorflow-bin in nixpkgs is also broken.  It's my personal opinion...  I say that nix has become mainstream in the nix community recently, but I think it is difficult to become mainstream as long as these problems exist.  I hope you put jupyterwith into nixpkgs main

@PlumpMath  sorry I've been busy with other responsibilities. The current master branch will be replaced with the main branch soon. I have tested the rust kernel in the main branch and it works.

#djacu Thank you Okay. I am waiting.
Change from main back to master ?
are we going back
Should I choose main or master?

I success building at Nixos & wsl nixos.
But failed nix-darwin.
I will always wait on this matter.
Thanks

Darwin does have some issues. It is on the roadmap to fix.


deserialize: flexible defaults for missing struct fields

Currently I have to define a newtype (eg: "BoolDefaultTrue") every time I want an optional struct field to have a non-Default::default() default, which is clumsy.  Ideally I could just say something like:
struct Foo {
    #[serde(default=true)]
    enabled: bool,
}

... and this would fill in the value true if it was missing from the serialised string.  Super-awesome would be if serde also generated a Default trait implementation for Foo that respected the same values, but I could understand that being considered out of scope.

If you create a manual Default impl for Foo, serde still uses the Default impl of the fields` type.
Example: this impl doesn't cause the #[serde(default)] to set the field to true.
impl Default for Foo {
    fn default() -> Foo {
        Foo {
            enabled: true,
        }
    }
}

@erickt: is using the surrounding type's Default impl (if present) too much magic? Alternatively requiring that the type impls Default if any field is annotated would be a breaking change and maybe not what one expects when annotating a field.

This was implemented in #238!

Yep, this is now doable with the #[serde(default="...")] attribute. I think this issue can be closed.


Adding CheckExists that only returns an error

Adding this convenience function if you're only interesting in the existence of an element and maybe want to pass any error through.
This avoids having to write:
// The more inconvenient way to check for existence:
if _, err := repo.Exists(ctc, "foo", id): err != nil { /*...*/ }

// Adding a little more convenience
if err := repo.CheckExists(ctc, "foo", id): err != nil { /*...*/ }

The Exists function itself always returns a not-nil error value if the object with the given id doesn't exist. That's why we can focus on the error and leave the boolean return value alone.

Codecov Report

Merging #1428 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1428   +/-   ##
=======================================
  Coverage   60.32%   60.32%
=======================================
  Files         119      119
  Lines       11134    11134
=======================================
  Hits         6717     6717
  Misses       3762     3762
  Partials      655      655

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 a5b95d8...9d4b716. Read the comment docs.

@kwk why do we need to create a function for this ? Then maybe the repositories should implement checkExists instead... I am confused

@kwk why do we need to create a function for this ? Then maybe the repositories should implement checkExists instead... I am confused

Because we effectively only have the Exists function to fullfil the Go standard of returning a bool and an error. I argue that only the error is useful.

[test]

@kwk I'll cherry pick this function. Closing this PR in favor of https://github.com/fabric8-services/fabric8-wit/pull/1415


[SPARK-35263] [TEST] Refactor ShuffleBlockFetcherIteratorSuite to reduce duplicated code

What changes were proposed in this pull request?
Introduce new shared methods to ShuffleBlockFetcherIteratorSuite to replace copy-pasted code. Use modern, Scala-like Mockito Answer syntax.
Why are the changes needed?
ShuffleFetcherBlockIteratorSuite has tons of duplicate code, like https://github.com/apache/spark/blob/0494dc90af48ce7da0625485a4dc6917a244d580/core/src/test/scala/org/apache/spark/storage/ShuffleBlockFetcherIteratorSuite.scala#L172-L185 . It's challenging to tell what the interesting parts are vs. what is just being set to some default/unused value.
Similarly but not as bad, there are many calls like the following
verify(transfer, times(1)).fetchBlocks(any(), any(), any(), any(), any(), any())
when(transfer.fetchBlocks(any(), any(), any(), any(), any(), any())).thenAnswer ...

These changes result in about 10% reduction in both lines and characters in the file:
# Before
> wc core/src/test/scala/org/apache/spark/storage/ShuffleBlockFetcherIteratorSuite.scala
    1063    3950   43201 core/src/test/scala/org/apache/spark/storage/ShuffleBlockFetcherIteratorSuite.scala

# After
> wc core/src/test/scala/org/apache/spark/storage/ShuffleBlockFetcherIteratorSuite.scala
     928    3609   39053 core/src/test/scala/org/apache/spark/storage/ShuffleBlockFetcherIteratorSuite.scala

It also helps readability, e.g.:
    val iterator = createShuffleBlockIteratorWithDefaults(
      transfer,
      blocksByAddress,
      maxBytesInFlight = 1000L
    )

Now I can clearly tell that maxBytesInFlight is the main parameter we're interested in here.
Does this PR introduce any user-facing change?
No, test only. There aren't even any behavior changes, just refactoring.
How was this patch tested?
Unit tests pass.

Test build #138054 has started for PR 32389 at commit 322593f.

Test build #138054 has finished for PR 32389 at commit 322593f.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138054/

Test build #138055 has started for PR 32389 at commit c96a16e.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42573/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42573/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/42573/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42574/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42574/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/42574/

Test build #138055 has finished for PR 32389 at commit c96a16e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138055/

cc @Ngone51 @mridulm FYI

This's a great refactor. I left some minor comments. Overall, looks good to me.

Thanks @Ngone51 for the suggestions!
I put up two more commits. The first pretty directly answers your comments and has some other small fixes I noticed.
The second one is a bit larger and was inspired by your comment about moving the helper methods from the object to the class. All of the tests make use of val transfer = mock(classOf[BlockTransferService]) and then pass this around to the helper methods. I moved this to be a field instead and then we can remove transfer from being passed in the method signatures. I think it's cleaner but open to feedback on that part, I am happy to revert if you/others don't find it useful.
It does reduce the size by another ~40 lines:
> wc core/src/test/scala/org/apache/spark/storage/ShuffleBlockFetcherIteratorSuite.scala
     894    3509   37951 core/src/test/scala/org/apache/spark/storage/ShuffleBlockFetcherIteratorSuite.scala

Test build #138087 has started for PR 32389 at commit 596c3dd.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42607/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42607/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/42607/

@Ngone51 do you have any more comments here? Thanks a lot for your comments so far!

Test build #138641 has started for PR 32389 at commit 4fcc6be.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43161/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43161/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/43161/

Test build #138641 has finished for PR 32389 at commit 4fcc6be.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138641/

Test build #138690 has started for PR 32389 at commit eea80f5.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43211/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/43211/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/43211/

Test build #138690 has finished for PR 32389 at commit eea80f5.

This patch fails SparkR unit tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138690/

Merging to master, thanks @xkrogen.
Thanks for the reviews @Ngone51 , @otterc !

Thanks for the reviews @mridulm , @otterc, and @Ngone51 ! Much appreciated.


How to call nanopolish methyltrain

Hi!
Perhaps I wasn't looking hard enough, but I was unable to find documentation on methyltrain, so I tried to understand it from the source code.
One thing I don't understand is: How should the training data be prepared? I am trying to train an ACGMT alphabet, but it looks like it fails to find any of the events that contain an "M" base. How do I tell nanopolish which bases are methylated and which aren't? Does it need the "M" base in the fastq file, or in the bam file, or in the reference, or in all?
Thanks a lot!
Rene

Sorry, methyltrain still isn't very well documented. You might want to look at nanopolish train in the r10 branch, which is somewhat simpler to use. Its still in pre-release though.
To answer your question, the M bases need to be in the reference genome.
Jared


AWS Superseded Instances Remediation Policy

Description
This policy searches for an instance of a specific type and takes action on it.
Issues Resolved
[List any existing issues this PR resolves]
Contribution Check List

[ ] All tests pass.
[ ] New functionality includes testing.
[ ] New functionality has been documented in the README if applicable
[ ] New functionality has been documented in CHANGELOG.MD

@avinashbhashyam-rs I thought the rs_cm. calls default to 1.6 if available? is there an option on those resources calls if not to use 1.6?

@rshade : No. rs.cm always uses API 1.5. and we don't have an option to specify it to use 1.6. You have to use right_api 1.6 as a http datasource.

@avinashbhashyam-rs would that break my excludes tags list?

@rshade : Yes. The tags filter is only available on resources. But the index call returns the tags set on the instance so you need to check for the exclude tags in java script.


Fix https://github.com/NoHomey/material-ui-number-input/issues/12

#12
I doubt the change to webpack.config.js is needed, but I couldn't get it to compile otherwise.

One of the things I notice in 2.2 release of TypeScript was the Object type but did not had time to update. I think it would be better to use the new builtin type instead of the object literal :smile:

The only changes should now be exactly those object literals to the object type. I'm trying to get this package into my project as soon as I can, so a merge would be most appreciated.
Let me know if you need anything else on this PR!


[suggestion] Events listening timeout

Feature request
I'd like to have the ability to listen to events with a given timeout.
I see the function signature in this way:
pub fn listen_for_events(
        &self,
        event_filter: FilterBox,
        timeout: Option<Duration>, // time after which the connection will be closed
) -> Result<impl Iterator<Item = Result<Event>>> {

Motivation
Currently, the client library doesn't provide a way to listen to events with some specific timeout.
Who can help?
@Erigara @appetrosyan

seems to work for asynchronous methods, but not synchronous

doesn't seem very relevant

The problem seems to be that submit_transaction_blocking internally uses listen_for_events and never times out if transaction has been rejected before being stored in a block. I think that if transaction is rejected during validation it is store in the block and submit_transaction_blocking will not hang in that case. We have to cover cases where transaction is eagerly dropped


No resize / crop option for layer?

It's the only thing holding this editor back.
One want's to be able to zoom in on a face from an artwork for example.

@geoidesic I assume you mean the ability to tokenise soemthing if you don't art work for it? Meaning the following screen:

That's another module that I'm leveraging. Any changes to that will have to be requested on it's github:
https://github.com/mrprimate/vtta-tokenizer


Array as parameters of DataRequest, encoding fails.

What did you do?
ℹ I want to put a Array<String> as parameters of DataRequest, but it failed.
What did you expect to happen?
ℹ I read the document, and it tells Encoding of Array Parameters https://github.com/Alamofire/Alamofire/blob/master/Documentation/Usage.md#configuring-the-encoding-of-array-parameters  is available, so it should be ok for my case.
What happened instead?
ℹ The response i got is .fail, and i debug the codes then found that one judgement support .object(xx) but .array(xx), it is confusing.
Alamofire Environment
**Alamofire version: 5.2.1
**Xcode version: 11.4
**Swift version: 5.0
**Platform(s) running Alamofire: iOS 13.4.1 iPhone Xr
**macOS version running Xcode: macOS Catalina 10.15.4(19E287)
Demo Project
ℹ These blow are my codes, thank you very much.

Initialize the DataRequest:

else if let parameters = request.parameters as? Array<String>  { // [String]
dataRequest = self.sessionManager.request(url,
                                                                            method: request.method,
                                                                            parameters: parameters,
                                                                            encoder: URLEncodedFormParameterEncoder(encoder: URLEncodedFormEncoder(arrayEncoding: .brackets), destination: .httpBody),
                                                                            headers: HTTPHeaders.init(allHeaders))
}

As you see, parameters is type of Array<String>.

encoder handle:

As you see, the result is that component is case .array(xxx) = component,
but the guard case let .object(object) = component expression throw an error.

response:

The request is not sent.

I wonder why it can not success,  of course i can use another way to make it:
// parameters is Array<String>.
guard let data = try? JSONSerialization.data(withJSONObject: parameters, options: []) else {
                return
            }
            let paramString = String(data: data, encoding: String.Encoding.utf8)
            var urlReq = URLRequest(url: url)
            urlReq.httpMethod = request.method.rawValue
            urlReq.httpBody = paramString?.data(using: .utf8)
            urlReq.headers = HTTPHeaders.init(allHeaders)
            dataRequest = self.sessionManager.request(urlReq)

Thank you.

Yes, URL form encoding requires a root object to label the array elements. Do you have an example of the result you expect?

As this is a required behavior for URL form encoding, I don't think there's anything to do here.


Add version badge to Readme

Because the more badges you have, the cooler your project is. 😎
But seriously, it would be nice to pull up the readme and see the current version without having to scroll.

🙇 dude we gotta get some progress spinners and more emoji too


No such service ComponentInfo

I have created a PeriodicWorkRequest that will run every 24 hours, i am calling this Workmanger from the Application class, here is my code snippet of declaration.
PeriodicWorkRequest.Builder myWorkBuilder =
new PeriodicWorkRequest.Builder(DeleteRecord24HourWorker.class, 24, TimeUnit.HOURS);

        PeriodicWorkRequest myWork = myWorkBuilder.build();
        Configuration myConfig = new Configuration.Builder()
                .setMinimumLoggingLevel(android.util.Log.INFO)
                .build();

        WorkManager.initialize(this, myConfig);
        WorkManager.getInstance(this)
                .enqueueUniquePeriodicWork("deleterecord", ExistingPeriodicWorkPolicy.REPLACE, myWork);

AndroidManifest.xml
<provider
            android:name="androidx.startup.InitializationProvider"
            android:authorities="${applicationId}.androidx-startup"
            android:exported="false"
            tools:node="remove">

        </provider>

Here is the exception that I am getting in logcat
E/WM-SystemJobScheduler: Unable to schedule {WorkSpec: 59cb6a4d-bbbf-4855-85ea-fe85ef625dec}
java.lang.IllegalArgumentException: No such service ComponentInfo{com.example.kiosk/androidx.work.impl.background.systemjob.SystemJobService}
at android.os.Parcel.readException(Parcel.java:2017)
at android.os.Parcel.readException(Parcel.java:1959)
at android.app.job.IJobScheduler$Stub$Proxy.schedule(IJobScheduler.java:180)
at android.app.JobSchedulerImpl.schedule(JobSchedulerImpl.java:44)
at androidx.work.impl.background.systemjob.SystemJobScheduler.scheduleInternal(SystemJobScheduler.java:187)
at androidx.work.impl.background.systemjob.SystemJobScheduler.schedule(SystemJobScheduler.java:133)
at androidx.work.impl.Schedulers.schedule(Schedulers.java:108)
at androidx.work.impl.WorkerWrapper.onWorkFinished(WorkerWrapper.java:375)
at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:331)
at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764)

@pfmaggi @calren can you please take look into this? can you please guide me what wents gro

Thanks for reporting this.
I'm closing this issue because this forum is for issues with the codelab.
You may take a look on how to configure WorkManager to increase its debug level as documented in this guides to get a better understanding of what is happening in your code. Also you can find a sample in this codelab.
If you still have this problem, Stackoverflow might be a better forum for this kind of questions.
If you think that this is a problem of the WorkManager library, please open a bug on the WorkManager public issue tracker: https://issuetracker.google.com/issues/new?component=409906&template=1094197
Please reopen if you still think this is an issue with the codelab.


Spanners don't set breakable_length as expected

Spanner is a mixin meant to be combined with PositionedObject classes. Spanner provides an implementation of breakable_length, but this implementation is not always used in concrete classes due to multiple inheritance weirdness. This can be seen in the fact that octave line spanners do not repeat their indication text at the beginning of every line as expected.

this should be fixed in 0.1.13


chore: add covector for version automation

Current dependencies on/for this PR:

main

PR #6   👈

This comment was auto-generated by Graphite.


New PR on different branch to get OSGI Bundle creation from OODT packages

As discussed, Moved to a new branch so I can tinker with this over the next few weeks to make sure the OSGI bundles work properly.

@buggtb what's the status of merging this?

Much closer now the new dependency stuff is merged.  I didn't want to have
to redo it. I'll take a look once the kids have been banished
On 16 Oct 2015 17:28, "Chris Mattmann"<EMAIL_ADDRESS>wrote:

@buggtb https://github.com/buggtb what's the status of merging this?
—
Reply to this email directly or view it on GitHub
https://github.com/apache/oodt/pull/26#issuecomment-148761666.

Ran out of time last night, I'll have a look tonight, hopefully the
Spartans vs Wolverines isn't too much of a distraction....
On 16 October 2015 at 17:32, Tom Barber<EMAIL_ADDRESS>wrote:

Much closer now the new dependency stuff is merged.  I didn't want to have
to redo it. I'll take a look once the kids have been banished
On 16 Oct 2015 17:28, "Chris Mattmann"<EMAIL_ADDRESS>wrote:

@buggtb https://github.com/buggtb what's the status of merging this?
—
Reply to this email directly or view it on GitHub
https://github.com/apache/oodt/pull/26#issuecomment-148761666.

Hail to the victors

This is against a branch in the official repo, so i'm going to merge it in, close it and the work off the main repo which will make my life easier as the rest of my dev work is now against branches in the main repo.

Pushed changes to osgi-plugin branch, will tidy up from there.


label does not have a for attribute or a labeable child — wrong for custom elements

This error is not helpful for custom-elements. It should turn into a warning or be suppressed if there's a custom-element child.
This generates the error:

    Toggle Me
    <b8r-switch
      height="12px"
      data-bind="
        value=web-component-demo.toggle;
        attr(onColor)=web-component-demo.onColor;
        attr(color)=web-component-demo.offColor;
      "
    ></b8r-switch>

@tonioloewald this project is not really maintained anymore. I suggest you to use LintHTML  instead

Thanks for taking the trouble to reply to me! I'll check out LintHTML.
On Wed, Feb 12, 2020 at 2:24 AM Benjamin JEGARD<EMAIL_ADDRESS>wrote:

@tonioloewald https://github.com/tonioloewald this project is not
really maintained anymore. I suggest you to use LintHTML
https://github.com/linthtml/linthtml instead
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/htmllint/htmllint/issues/271?email_source=notifications&email_token=AAHPD7ZSZMF7OT7POWMCXJTRCPE7DA5CNFSM4KMJVH42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELQHWDI#issuecomment-585136909,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHPD7ZW7VNJKXJGJW4SWXDRCPE7DANCNFSM4KMJVH4Q
.

--
Tonio Loewald | p:<PHONE_NUMBER> | web: loewald.com


Settings for DataReceived on background worker

Added a setting that allows the user to control whether the DataReceived event is fired in a background worker or in the DataRecevier thread.
Added unit tests for this setting.

Thanks for putting this together @TheNybbler - I made some minor changes (naming) and also added the same setting for the client side.
NuGet: https://www.nuget.org/packages/SuperSimpleTcp/3.0.1
Commit: https://github.com/jchristn/SuperSimpleTcp/commit/29165a7d487fe7fcfe0af04657bf6ab338d2bec7


DatePicker Mobile Cancel Still Changes Value

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
When you open the mobile datepicker modal, and select a new date, then hit cancel, the selected value has become the value of the input, instead of remaining the original value.
Also, this would make sense to use onAccept and onClose but onChange is required. Little confusing setup.
https://user-images.githubusercontent.com/10913613/152169659-de2f5f94-d1d0-4083-a0ba-1e06d14583f5.mp4
Expected behavior 🤔
Clicking cancel should not change value
Steps to reproduce 🕹
Steps:

See video from Material UI website

Context 🔦
No response
Your environment 🌎
No response

Duplicate of https://github.com/mui-org/material-ui/issues/30731


Must reference equality really be supported?

@dbernhard-0x7CD's tests include comparing references, for example, in
https://github.com/nicdard/compiler-design-eth-tests/blob/main/05/dbernhard/equality.oat#L25
I wonder, though, whether supporting this is really necessary for this homework. Although the rules Typ_Eq and Typ_Neq imply that it should be supported, the provided frontend does not implement this (see lines 246 - 252). Also, I did not find any indication anywhere else that we're supposed to add this.
Am I missing something?

I think we should create a moodle post; I only implemented it because it was possible according to the grammar and TC rules.

It's not necessary: https://moodle-app2.let.ethz.ch/mod/forum/discuss.php?d=93403#p199796


Error pickling MCNP_Problem: Cannot pickle 'generator' object

Cannot pickle montepy.MCNP_Problem objects.
Describe the bug
Since v0.3.0, can no longer pickle montepy.MCNP_Problem for more complicated input decks. The MCNP_Problem contains an unpicklable generator object. Rolling back to v0.2.10 fixes this.
This is not caught by tests/test_interface.py::TestBrinyFermentation .
To Reproduce / Error Message
>>> deck = montepy.read_input("path/to/input.imcnp")
>>> with open("path/to/pickle.pkl", 'wb') as pkl:
...    pickle.dump(deck, pkl)
TypeError: cannot pickle 'generator' object

MCNP input file snippet
I am working on producing a MWE to reproduce this error.
Versions

0.3.0,
0.3.1,
0.3.2

This sounds familiar to an old issue.

Issue #189
Something broke the ability to pickle inputs between then and now (for inputs with some as-yet unidentified complexity that is not tested).

Tallies break it.
test_tal.imcnp
MCNP Test Model for Tallies
1 1 20 -1000  imp:n,p=1 U=350 trcl=5
2 2 8  -1005  imp:n=1    imp:p=0.5
3 3 -1  1000 1005 -1010 imp:n,p=1
99 0 1010     imp:n,p=0
5 0   #99     imp:n,p=3 fill=350 (1 0 0 )

C surfaces
1000 SO 1
1005 RCC 0 1.5 -0.5 0 0 1 0.25
1010 SO 3

C data
C materials
C UO2 5 atpt enriched
m1        92235.80c           5 &
92238.80c          95
C Iron
m2        26054.80c        5.85
          26056.80c       91.75
          26057.80c        2.12
          26058.80c        0.28 $ trailing comment shouldn't move #458.
C water
m3        1001.80c           2
          8016.80c           1
MT3 lwtr.23t h-zr.20t h/zr.28t
C Tallies
f7:n 1
C execution
ksrc 0 0 0
kcode 100000 1.000 50 1050
phys:p j 1 2j 1
mode n p
vol NO 2J 1 1.5 J

Created #468 to test this.

Thanks for doing this. I'm not sure if tests/inputs/test.imcnp is the best place for this though. Every time the file is updated a lot of tests have to be updated because I hard code in what the file is in a lot of places. Probably not the best test design.

Long term: https://docs.python.org/3/library/pickle.html#object.reduce this is probably a solution that is needed along with #193.

Discovered this breaks copy.deepcopy as well now.

This is suddenly very useful for some of my production work leveraging MontePy.


defaultKeepStorage supported in pull-through cache mode

According to docker documents, registry will periodically removes old content to save disk space.
But I really couldn't predict when & what cache would be remove. Furthermore, is there a similar parameter like defaultKeepStorage to help users define how much disk they want to use for this cache system?
/cc @milosgajdos

type proxyBlobStore struct {
	localStore     distribution.BlobStore
	remoteStore    distribution.BlobService
	scheduler      *scheduler.TTLExpirationScheduler
	repositoryName reference.Named
	authChallenger authChallenger
}
```
There is a TTLExpirationScheduler for proxyBlobStore, which will clean the image that is expired. And the duration could be configured. Is this feature what you need?

I reconsider the feature again. You demand is cleaning image based on the disk usage, that is different with the current way of cleaning.


Column names in Analyze object do not match

---sorry I closed the previous same-named issue by mistake ---still open
Hello,  just recognised that the Analyze object's column names do not match the content of the params dictionary...see the examples below:  I've ran an experiment with the following params:
p = {'optimizer': [Adam, Adamax, Nadam, Adagrad, Adadelta], 'first_neuron': [5120, 1024, 512, 128, 64, 32, 16], 'batch_size': [100, 1000, 5000, 10000], 'epochs': [25], 'hidden_neuron':[1024, 512, 128, 64, 32, 16, 8, 4, 2], 'hidden_layers':[0, 1, 2, 3, 4], 'kernel_initializer': ['uniform', 'normal', 'glorot_uniform'], 'dropout': [0.0, 0.25, 0.5, 0.65, 2, 3, 4, 5, 10], 'losses': ["mape", "mse"], 'shapes': ['brick', 'triangle', 'funnel'], 'activation': ['relu'], 'lr': [0.0001, 0.0002, 0.0005, 0.0009, 0.001, 0.002, 0.005, 0.009, 0.01, 0.02, 0.035, 0.05, 0.075, 0.09, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9] }
After finishing and analyzing the resulting csv file as an analyze object, I get the following result:
dir = "TalosPipeline1/"
file = "101919222627.csv"
t = talos.Reporting(dir + file)
t2 = talos.Analyze(t)
t2.data.head()
As you see in the image below, e.g. the optimizier column is showing floats and the first_neuron column is showing functions.  Am I doing something wrong or is this a bug?

additional comment: Maybe the screenshot below helps...it seems that the dataframe has the exact same order, as the param print out while running. But alphabetically ordered column names.
I tried to read through your code concerning the paramter setting, but I couldn't find the place, where this happens.
Maybe somebody can?!

thanks and br
christoph

Can you do:
import talos
talos.__version__

What do you get?

'0.6.3'

Related with #439

thanks...it's working now!


Add druid.indexer.server.maxChatRequests for QoS; deprecate separate ports.

Add druid.indexer.server.maxChatRequests, which sets up a QoSFilter on the main Jetty server.
Deprecate druid.indexer.runner.separateIngestionEndpoint
Deprecate druid.indexer.server.chathandler.*

see discussion on #2419

@gianm
Running io.druid.server.initialization.JettyQosTest
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 53.158 sec <<< FAILURE! - in io.druid.server.initialization.JettyQosTest
testQoS(io.druid.server.initialization.JettyQosTest)  Time elapsed: 52.729 sec  <<< FAILURE!
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at io.druid.server.initialization.JettyQosTest.testQoS(JettyQosTest.java:191)

@nishantmonu51 can you take a look?

@fjy fixed the test

:+1:

would like feedback from at least a couple of @nishantmonu51 @drcrallen @guobingkun @pjain1 or @cheddar on this one, as it is a follow up to https://groups.google.com/forum/#!msg/druid-development/hfCggehFl_I/INfjEyxbBQAJ and deprecates the feature introduced in #1929.

looks good to me, :+1: from my side, still keeping it open for others to review it.

Suggest leaving open and bringing up in the dev sync to see if anyone wants to comment (also stating why this PR is needed). Then merge if no comment.

I didn't look too closely, but the goal of #1929 was to provide for clear separation of ingestion and query resources.  As long as this maintains that (which it looks like it does), I'm on board.

:+1:


Bug Report: In certain situation, heading would be ignored.

When two headings are adjacent to each other with no content separator in between, the last heading is ignored.
For example:
## HEAD1
    ### SubHead1
    ### SubHead2
## HEAD2
## HEAD3

The result would be:
HEAD1
---SubHead2
HEAD3
As you can see, subHead1 and HEAD2 are ignored.

like that?

could you share the file in question here?

thanks for clarifying. — should be fixed in the latest version.


fix lilyweight [B]: remove lilyweight

This PR is to fix lilyweight dungeon weight returning NaN, caused by new M7 floor.
This fix simply prevents lily weight from being printed in front end. We will re-enable it once the npm package gets updated with a fix.

It would be nice to display a message explaining what happened instead of just removing it


cli: Create CLI tool to run troubleshooting tooling

This GitHub Issue is for the design and implementation of a new OSM CLI tool (for instance: osm trouble), which runs a certain set of functions and inspects the Kubernetes cluster, SMI CRDs, Ingress, Services, Endpoints, Envoys (and other sidecars), Envoy configs and points to potential issues, even offers potential fixes.

[ ] Design a high level framework

[ ] osm trouble --? - what options could be provided to this?
[ ] The tool should ask the operator to provide as much context around the issue they are troubleshooting as possible (optional CLI arguments or interactive questions)

[ ] provide source pod
[ ] provide destination pod
[ ] provide namespace where the issue is
[ ] is there a specific SMI policy that we are having issues with?
[ ] is there certain Service Account or Service which is relevant

The tool would run various functions for scenarios we have added to pkg/troubleshooter

hasAccess(sourcePod, destinationPod)
or hasAccess(sourceServiceAccount, destServiceAccount)
or envoyHasInboundPolicy(service)

(ideas) Questions the tool could/should answer:

osm trouble --namespace=irc  - provide everything we know about the namespace irc from the perspective of OSM:

is OSM enabled on that namespace
is it enabled for Envoy injection
is it annotated for metrics collection
is this namespace port of a mesh? which mesh
list services and service accounts
show matrix of pods that have access to each other

osm trouble --pod=xyz  - gives all the context of a pod

are metrics enabled,
is it injected,
what services does it host,
what service cacount,
what does it have access to etc.
Is it affected by Ingress.
Is egress alowed.

other troubleshooter ideas

is a mesh installed at all
what namespaces are annotated for injection
what namespaces are annotated for metrics

are there other OSMs installed on the cluster

are there any other Service Meshes (not OSM) that are installed

are there other sidecars (pods with more than 1 container)

Duplicate of osm-health, and we have https://github.com/openservicemesh/osm/issues/4101 to track osm-health integration into osm cli.


Update login history to get the latest version starting at 1.1

This change updates the login-history to get the latest version starting at 1.1, previously it locked it into the rc2 version

:tada: This PR is included in version 4.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket: