DOC101: allow whitelisting specific arguments from being required for the docstring

Especially when it comes to tests, there is a series of pytest fixtures that do not really need any documentations. A simple example would be the code below:
@pytest.fixture(autouse=True)
def _no_color(monkeypatch: pytest.MonkeyPatch) -> None:
    """Disable coloring output.
    ...

I do think that if we could define a list of keywords / args that would not need to be documented, we could sort this problem.
Update with other attributes/arguments that we do not want to document:
__metaclass__
__next__

Hi @ssbarnea , the risk of excluding certain arguments is ambiguity and communication overhead.
For example, you don't want arg1 and arg2 to ever be checked by pydoclint.  Then what should pydoclint do if it finds documentations of arg1 and arg2 in the docstring, especially, if the documentation of arg1 and arg2 is partially correct (e.g., correct name, incorrect type hint)?  Should pydoclint report a violation?
If pydoclint doesn't need to complain, future maintainers of the repo may get super confused (because they see that some args can "get away" with being wrong).  They'd either need to ask the initial authors, or come and ask me.  All this, in my opinion, is communication overhead that slows a team down.
If, on the other hand, you'd want to exclude certain functions/classes/methods from being checked by pydoclint, it is supported via flake8.  You can put # noqa: DOC at the line of function/classes definition.

I'm closing this issue now.  If there are additional things that I missed, please feel free to add a comment here or open a new issue.


Add current control to vesc driver

This allows a user to use the throttle command to control the vesc via current (acceleration). The values for the current should fall between [-1, 1]

There are some tuning adjustments that can be done in the vesc itself and at the hardware level which will make driving with current control much smoother

Just a couple of lint errors from the ROS1 CI, otherwise looks good to me.

I literally just pushed the changes up to the branch! Sorry it took a bit to get to it. If you want, I can open a new PR with the linter fixes?

Haha yea, you can open a new PR.


Add manylinux wheel support and fix a few bugs along the way

Adds support for manylinux1_x86_64 and manylinux1_i686 platforms. I've treated them as platforms, because that's how PEP-513 describes them. This fixes #281.
Fixes a number of bugs related to the handling of wheels that have hyphens in the package names (e.g., cassandra-driver and msgpack-python).
Fixes a couple places where str.replace was being called without storing the result (thereby accomplishing nothing since str is immutable)

Will update test data so they pass.

Tests now pass

@dan-blanchard awesome. let me know if/when this is ready for review and I'd be happy to take a look.

This is all ready for review

One thing that this doesn't handle that I was worried about is detecting whether a platform actually supports manylinux: https://github.com/pantsbuild/pex/issues/281#issuecomment-231124725
I didn't have a chance to think about where to add runtime compatibility checking in PEX though.

One thing that this doesn't handle that I was worried about is detecting whether a platform actually supports manylinux: #281 (comment)

Would there be any objections to adding pip as an explicit dependency for pex? It seems silly to reimplement a lot of the work they've done on checking for manylinux compatibility when we could just call pip.pep425tags.is_manylinux1_compatible().

One thing I've noticed with this PR that the wheels it picks aren't don't always match the ABI tags they should. At first I thought this was just when using the --platform tag on OS X, but even without --platform I've found that on Linux I get some cp27m wheels and some cp27mu wheels in the same archive. I think maybe we'll need to add the ability to specify an ABI tag when using --platform and we should use pip.pep425tags.get_abi_tag() to determine the correct ABI tag without it.

Also, more about the depending on pip thing... pypa/pip@bbe99ce62d626f6c01552c3fcab953b014674c53 adds support for downloading packages for different interpretters and ABIs to pip. It feels like all the fetching/downloading stuff pex is doing could just piggyback on pip and pex could just concentrate on building the zip with __main__.py.

@dan-blanchard

Would there be any objections to adding pip as an explicit dependency for pex?

I think it'd be great if we could avoid that for now just due to precedent/historical reasons, but wouldn't be opposed in the longer term if a proposal materialized that thoughtfully motivated the case.

One thing I've noticed with this PR is that the wheels it picks don't always match the ABI tags they should.

yeah, this is a semi-known wart with current pex that is particularly relevant for shops without isolated indexes. pex differs from (pre-8.0) pip et al because fundamentally you can build a pex on one host and run it on another which may or may not share the same abi compatibility. I think to solve this, we probably would want to plumb an explicit argument or other config for constraining the resolve to only allowable flags with some sensible defaults. the runtime resolve checking should probably also detect compatible abis and error early if they fail to resolve - which could additionally pave the way for multi-abi pexes (e.g. one pex with both m and mu wheels that could exec on ucs2 and ucs4 systems and use the right deps accordingly). feel free to file an issue for this one if you have time.

It feels like all the fetching/downloading stuff pex is doing could just piggyback on pip ...

yes, totally. we've effectively been waiting (roughly >a year now) on the change/set of changes you mentioned (patricklaw is also a pants/pex contributor) to land in pip to create a path for us to move to a pluggable resolver model that would let us slot pip directly into pex for resolution. this would allow us to deprecate the bespoke pex resolver in favor of pip's while also providing a backwards-compatible upgrade path. it's something we want to do, but is relatively invasive and at odds with other priorities - so if you had any interest in picking that work up, it'd be most welcome.

@dan-blanchard what were you thinking here in terms of best way to proceed? perhaps a quick --manylinux flag in this PR defaulting to off to explicitly turn on this behavior - and then circling back with improvements around the abi/capability detection before defaulting that to on?

what were you thinking here in terms of best way to proceed? perhaps a quick --manylinux flag in this PR defaulting to off to explicitly turn on this behavior - and then circling back with improvements around the abi/capability detection before defaulting that to on?

Yeah, that seems reasonable to me. I'll try to set that up soon.

I just pushed a commit that I haven't updated the tests for yet, so it will likely fail, but it adds the CLI options necessary for finding the correct wheels for different platforms. I was unable to do this change in a backward-compatible way, so this will need a major version bump if people are using the internal PEX API. The biggest change is that I copied out pip's pep425tags module and started using that all over the place. This will make sure that we won't default to using manylinux wheels on Linux interpreters that aren't manylinux compatible.
There's some cleanup that's still left to do, but I wanted to show y'all what I had so far.

I've built actual manylinux PEXs with this thing branch and they work fine. I cannot for the life of me figure out why the tests are failing right now. Would love another set of eyes.

Tests are now passing for everything but pypy. I'll dig into that, but this could use another look now that it's gotten a bit bigger (because I fixed the issue where PEX would download wheels for the wrong ABI tags).

The PyPy tests were failing due to a strange special case in pip's PEP425 handling for PyPy that we're now using. I've fixed that and now ALL TESTS PASS.
@kwlzn, I know you already approved this, but it's grown a little bit in scope since you did that, so you might want to take another look.
Also, I know giant PRs are a total pain to review, so if this is too much to get through, I could split off the last two commits (which removed the old pep425 and platforms modules and replace them with pip's glibc and pep425tags modules) into their own PR. That would leave this PR basically like it was when @kwlzn approved it, but no one would actually be able to use the manylinux wheel support until the second PR was merged, because without the ABI compatibility fix, you end up with broken PEX files more often than not.
I did not add a --manylinux flag in the end because by switching to pip's pep425tags implementation we now check if a platform is manylinux compatible before trying to use those wheels.

Pinging for feedback as I believe the PR would address workarounds we have in place in our environment. Cheers!

thanks for updating the PR - I'm a bit swamped atm, but I'll try to carve out time to review sometime this week. apologies for the delay!

@kwlzn Thanks, no need to apologize. I maintain more projects than I should, so I know what it's like.

I was unfortunately not able to tackle this as I had hoped this week, but it's now at the top of my TODO list and will be diving in first thing on Monday as part of a pex 1.2.7 release (#379).

Just saw there were conflicts after the pre-release related changes, so I rebased.

I think it'd also be great if possible to at least pin the manylinux stuff down before this lands with a quick integration test. if you can find smaller manylinux wheels (<=300KB) for testing, feel free to commit them directly to the repo vs depending on pypi.

I'll try to dig some of those up tonight or tomorrow.

If it helps, I looked through pypi for manylinux wheels smaller than 300kB and found these
# size pkg url
296099 RelStorage-2.1a1-cp27-cp27m-manylinux1_x86_64.whl https://pypi.python.org/packages/15/51/6b158153470dd900d23f881da46206eec13fb2e38ab2e4d139bf5bb6b778/RelStorage-2.1a1-cp27-cp27m-manylinux1_x86_64.whl
289196 dumb_init-1.2.0-py2.py3-none-manylinux1_x86_64.whl https://pypi.python.org/packages/43/67/5697dd284b57c1839a1e4c5b9e8a50e2ccb6cffb00c53dbf03266204c49b/dumb_init-1.2.0-py2.py3-none-manylinux1_x86_64.whl
241958 msgpack_python-0.4.8-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/ba/f1/3e53ae3cede8715e7e06503660624d22372f84e7bc37f6ff96ed77b15863/msgpack_python-0.4.8-cp27-cp27m-manylinux1_i686.whl
236545 pyrilla-0.0.2-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/39/b5/2b97a67b4755de81889b7d7e80bfe00da71f59f0df0b593bea4badf7c3f3/pyrilla-0.0.2-cp27-cp27m-manylinux1_i686.whl
234604 python_bsonjs-0.1.1-cp26-cp26m-manylinux1_i686.whl https://pypi.python.org/packages/8d/bd/ce91ff40e990700cade754e887760a11b5aeda9957035f47811c692df639/python_bsonjs-0.1.1-cp26-cp26m-manylinux1_i686.whl
226251 japronto-0.1.1-cp35-cp35m-manylinux1_x86_64.whl https://pypi.python.org/packages/f2/7b/b711fbbeeeba2d747417d8903ad190a7ee977436da37432e44b204fce110/japronto-0.1.1-cp35-cp35m-manylinux1_x86_64.whl
218243 meinheld-0.6.1-cp36-cp36m-manylinux1_x86_64.whl https://pypi.python.org/packages/6f/66/442eba40331114798a4620373032bbb8f17be60609e7b12279eac644911c/meinheld-0.6.1-cp36-cp36m-manylinux1_x86_64.whl
196976 libMHCUDA-1.1.1-cp35-cp35m-manylinux1_x86_64.whl https://pypi.python.org/packages/87/25/b1814c8204258866fdd9308e5628f486c58f30cb4328db5c52a9f137b56f/libMHCUDA-1.1.1-cp35-cp35m-manylinux1_x86_64.whl
194387 opbeat-3.5.2-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/6b/25/fe40368bb3ac0e8dab31e46974c29666893131627db758f6e31972f1c549/opbeat-3.5.2-cp27-cp27m-manylinux1_i686.whl
191413 coverage-4.4b1-cp26-cp26m-manylinux1_i686.whl https://pypi.python.org/packages/71/15/5b03021f4da2d220d2e799b78e3bd477ab325baebe9a6a3eff99d6357a62/coverage-4.4b1-cp26-cp26m-manylinux1_i686.whl
188967 cchardet-2.0.0-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/0f/be/929162ca9fee3399eda89e59629136c16e1a88a058202a1b487dff8c7d05/cchardet-2.0.0-cp27-cp27m-manylinux1_i686.whl
161509 yarl-0.10.0-cp34-cp34m-manylinux1_i686.whl https://pypi.python.org/packages/eb/1d/2615e0dac685d0b0b9e3aa995b7293c75e4d4e4d6ab9e965635ee90fdb25/yarl-0.10.0-cp34-cp34m-manylinux1_i686.whl
158148 pytrip98-1.5.1-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/d2/07/503adf102b79e6bacbd03d45845f28a5345e98739b9d2ab19ffbffa56eea/pytrip98-1.5.1-cp27-cp27m-manylinux1_i686.whl
155489 bencoder.pyx-1.2.0-cp26-cp26m-manylinux1_i686.whl https://pypi.python.org/packages/24/a4/73ab3992a7ef5700fae247c2d81253ac5f68d4661af912ce4b226332e312/bencoder.pyx-1.2.0-cp26-cp26m-manylinux1_i686.whl
145494 secp256k1-0.13.2-cp27-cp27m-manylinux1_x86_64.whl https://pypi.python.org/packages/c8/22/95038ee6e1362f8177a1ad7af0912ae2de290710a8b292c04edc8e125420/secp256k1-0.13.2-cp27-cp27m-manylinux1_x86_64.whl
139323 PyLBFGS-<IP_ADDRESS>-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/e9/e0/ea444918b65bb8a1d80e73add89c840e4f8e689dd6b5dd201fac4f819a94/PyLBFGS-<IP_ADDRESS>-cp27-cp27m-manylinux1_i686.whl
135315 twisted_platform_support-16.12.3-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/f8/8d/1fd1a6ff65295a7fea71d030429a9e3eadcbae25fd12995302b8c4bf8370/twisted_platform_support-16.12.3-cp27-cp27m-manylinux1_i686.whl
130658 svmloader-0.4-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/e5/cd/172bf806bcc0e2759716984a5e22101b3d67f73c78555fe42341c9b1a2f4/svmloader-0.4-cp27-cp27m-manylinux1_i686.whl
123815 pendulum-1.2.0-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/4a/cc/e897d0a073e2b30d3fa16f65d972e4f9efeac49783b07f7262cb081e8f5d/pendulum-1.2.0-cp27-cp27m-manylinux1_i686.whl
103538 greenify-0.3.2-cp27-cp27m-manylinux1_x86_64.whl https://pypi.python.org/packages/94/96/60b1904ed211e1b37b1b58bf4e22cc6e709609c4374aec15095e9bf1836c/greenify-0.3.2-cp27-cp27m-manylinux1_x86_64.whl
98205 zopfli-0.1.1-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/b5/66/33b968013d54a84846b123e9cbdec627de80e7a800401ec52d9ef978b233/zopfli-0.1.1-cp27-cp27m-manylinux1_i686.whl
96341 numpy_sugar-1.0.35-cp27-cp27m-manylinux1_x86_64.whl https://pypi.python.org/packages/80/cc/fccc12a2311f4c7f7fbdb4c8208c4a67cc97ce0b3c9b8eacbc26460f6b91/numpy_sugar-1.0.35-cp27-cp27m-manylinux1_x86_64.whl
91474 ruamel.ordereddict-0.4.9-cp26-cp26m-manylinux1_x86_64.whl https://pypi.python.org/packages/7c/2d/552e914797da6f5a475452008f8450d4e3142ac2bcd59200356eed74e082/ruamel.ordereddict-0.4.9-cp26-cp26m-manylinux1_x86_64.whl
89084 ninja-1.7.2-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/3f/ca/8573f4b0a561c340776562e2465f55b2b1e352b61e2b929c627601e3d869/ninja-1.7.2-cp27-cp27m-manylinux1_i686.whl
87933 argon2_cffi-16.3.0-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/28/fe/a35f298c9a8887223ee29e30641205f23a97af91cf99a1fc9172bf4eede8/argon2_cffi-16.3.0-cp27-cp27m-manylinux1_i686.whl
79601 FXrays-1.3.3-cp27-cp27mu-manylinux1_x86_64.whl https://pypi.python.org/packages/11/bb/20649dfa9c82669ac7890b0ce04cb219760e48796f079a43b4f046875831/FXrays-1.3.3-cp27-cp27mu-manylinux1_x86_64.whl
74667 tonnikala-1.0.0b3-cp27-cp27m-manylinux1_x86_64.whl https://pypi.python.org/packages/65/fd/7ee2c5de0b057facefb493ced73a0794036fcee702022d6de7807801a2d0/tonnikala-1.0.0b3-cp27-cp27m-manylinux1_x86_64.whl
74061 cyrandom-0.1.3-cp35-cp35m-manylinux1_i686.whl https://pypi.python.org/packages/ae/61/610ab5d04df76002aad8e457338748b7564a602e4773b7adc9df529d9eb4/cyrandom-0.1.3-cp35-cp35m-manylinux1_i686.whl
72913 DoubleMetaphone-0.1-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/20/dc/a9fec6d53b0629f017e6ff9ee73cb50bc33b7aa7a4784187d7cedfde9b83/DoubleMetaphone-0.1-cp27-cp27m-manylinux1_i686.whl
71877 porridge-0.1.4-cp27-none-manylinux1_x86_64.whl https://pypi.python.org/packages/68/1d/f5a4b9265c8696fa98c9a91ef2c921221cae8f4a614445fe158a2b2d60f2/porridge-0.1.4-cp27-none-manylinux1_x86_64.whl
68933 dedupe-1.6.7-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/12/ab/54e107aecfb7b868c8925c4937f5e959e1aa627d0a1302cc3f8badba0057/dedupe-1.6.7-cp27-cp27m-manylinux1_i686.whl
67148 wsgi_lineprof-0.3.0-cp27-cp27m-manylinux1_x86_64.whl https://pypi.python.org/packages/d8/2a/3dbe75e2de52e19ea7a2cc8bc7596fba4ce4ed8b40fb92c7ba039d06145b/wsgi_lineprof-0.3.0-cp27-cp27m-manylinux1_x86_64.whl
66031 cymem-1.31.2-cp27-cp27m-manylinux1_x86_64.whl https://pypi.python.org/packages/e2/ef/e1ebaf55e478e1d34c6ac9b0d2fa8678e180542d3bc9398af9e95b546df1/cymem-1.31.2-cp27-cp27m-manylinux1_x86_64.whl
63569 sip-4.19.2-cp35-cp35m-manylinux1_x86_64.whl https://pypi.python.org/packages/19/5a/c50a0ccd211f864972da0f2e101722508ffb4e008347fd2a56a99beab9d0/sip-4.19.2-cp35-cp35m-manylinux1_x86_64.whl
58237 bcrypt-3.1.3-cp26-cp26m-manylinux1_i686.whl https://pypi.python.org/packages/58/24/a07d55c72180ff2d896dd0e94638e40c4d3a5fa6b4e367d6cd6c3e9919ba/bcrypt-3.1.3-cp26-cp26m-manylinux1_i686.whl
56730 lazy_object_proxy-1.2.2-cp26-cp26m-manylinux1_x86_64.whl https://pypi.python.org/packages/23/f9/f90b2953f858920959c25ab29cd856eb121f3267ce91cc27a4a4ecdf3712/lazy_object_proxy-1.2.2-cp26-cp26m-manylinux1_x86_64.whl
47998 pyquicklz-1.4.1-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/4f/d5/387ffa9031eba8ad7cb52cb64b848bf251ed855b343bc0b23bf9c960e298/pyquicklz-1.4.1-cp27-cp27m-manylinux1_i686.whl
47650 greenstack-0.6-cp26-cp26m-manylinux1_x86_64.whl https://pypi.python.org/packages/9f/ae/9bc8f3e0aa9eed8b83a29af76952a54033826019a250ce5aef4af212d407/greenstack-0.6-cp26-cp26m-manylinux1_x86_64.whl
42905 PyQtPurchasing-5.8-5.8.0-cp34.cp35.cp36.cp37-abi3-manylinux1_x86_64.whl https://pypi.python.org/packages/55/b7/3b603ce8685522ae11f894052e223ce467a6c8678b94a6e2cc9db194b637/PyQtPurchasing-5.8-5.8.0-cp34.cp35.cp36.cp37-abi3-manylinux1_x86_64.whl
41175 greenlet-0.4.12-cp26-cp26m-manylinux1_x86_64.whl https://pypi.python.org/packages/da/52/74bbc91f8bbdb0c3b475f294bb2b51deafad78efcd69eef2c853bc007c90/greenlet-0.4.12-cp26-cp26m-manylinux1_x86_64.whl
37825 affinegap-1.10-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/23/e5/4bb4d9e9341dfb62709fb42638a2e13199d3ef40b7fb32e14e379fe19626/affinegap-1.10-cp27-cp27m-manylinux1_i686.whl
35904 murmurhash-0.26.4-cp27-cp27m-manylinux1_x86_64.whl https://pypi.python.org/packages/7c/a9/0899d646b3806248ec93af2ee696fc72414781c4a5a1233fe51813960cbd/murmurhash-0.26.4-cp27-cp27m-manylinux1_x86_64.whl
23811 pandas_plink-1.1.6-cp27-cp27m-manylinux1_x86_64.whl https://pypi.python.org/packages/7a/c0/d8da30f905d1c8b947ccf8d72e9ba0cf3094baeab7ca672c6cfe9744f86e/pandas_plink-1.1.6-cp27-cp27m-manylinux1_x86_64.whl
23305 pycrypt-0.5.1-cp26-cp26m-manylinux1_i686.whl https://pypi.python.org/packages/6b/e6/65264364bfbd3a76e1476c94b4a41ff0962e875ed43fa3a29af7182cca95/pycrypt-0.5.1-cp26-cp26m-manylinux1_i686.whl
22590 json_cherry_pick-0.3.22-cp26-cp26m-manylinux1_i686.whl https://pypi.python.org/packages/2f/dd/94bb6995931237bebf91fa80f393baa2d1105b03d1d23c76c217c92a0b61/json_cherry_pick-0.3.22-cp26-cp26m-manylinux1_i686.whl
19338 sabyenc-3.0.2-cp27-cp27m-manylinux1_i686.whl https://pypi.python.org/packages/ea/f3/891da926c8728c132485e777554737ee0ebc085cff3c1b212920dec0eacf/sabyenc-3.0.2-cp27-cp27m-manylinux1_i686.whl
19263 arpreq-0.3.1-cp26-cp26m-manylinux1_i686.whl https://pypi.python.org/packages/77/34/cfbce43c41afd8773a12c9bfd9ad1e15c90c847ea387abe9cd2d151a52a9/arpreq-0.3.1-cp26-cp26m-manylinux1_i686.whl
18864 asyncwatch-0.1-cp35-cp35m-manylinux1_x86_64.whl https://pypi.python.org/packages/d9/76/d93a7a0457af70b60cbcdb8db3abdd52b45382a69d4dd4bc845cefb16fa2/asyncwatch-0.1-cp35-cp35m-manylinux1_x86_64.whl
11389 pyterminalsize-0.1.0-cp26-cp26mu-manylinux1_x86_64.whl https://pypi.python.org/packages/28/c3/542789262a7aafc935e85ab83cc8d1732401a843db0fd10100b6213d4356/pyterminalsize-0.1.0-cp26-cp26mu-manylinux1_x86_64.whl
2314 yftest-1.0.0-cp27-cp27mu-manylinux1_x86_64.whl https://pypi.python.org/packages/b8/73/0431ecd2ac0701e195c7fc99ab3b131fa32e45c5e8fa8bbb59742eabe2a9/yftest-1.0.0-cp27-cp27mu-manylinux1_x86_64.whl

Hi! Just a friendly ping ;) Really looking forward to seeing this pull-request is merged.

Very interested in seeing this in pex and eventually in pants. Not being able to use manylinux wheels without a hacky self-built cache is what takes up the majority of our build time (numpy, pandas, scipy stack)
Is there anything I can do to help this along?

I've fixed the merge conflicts here again, but I'm honestly not sure what the necessary next steps are at this point. We discussed possibly having another reviewer chime in about the CLI args. My initial idea behind them was to just make them match the ones pip uses, but then I added the --tags argument as @kwlzn and I discussed, so you could do either one.

@dan-blanchard as a mere user, I don't have a strong opinion on the tags thing--I just want something that will work for the platforms I care about (cp35-cp35m-manylinux1) that's integrated into the main release, so that I can eventually get it into at least my pants install.
That said, it looks like explicitly defining the full platform tag (analogous to gcc platform triples) is the way to go rather than assume some decomposition will work (combinatorial explosion + implicit pickup of new platforms from combinations). The space of platforms of built wheels is pretty sparsely populated at least from my casual look at pypi so it's not an issue to manually specify each platform at least for the initial version of this feature.
@kwlzn can I ask if there's anything stopping this from being merged? Apologies if I am intruding, I am just a happy user of pex

Rebased so this has latest master changes in it.

Would love to see this merged.  @kwlzn @dan-blanchard what are the next steps?

FWIW -- we're using this workaround for the time being: https://github.com/asottile/no-manylinux1

should have some cycles this week to get this in, but want to make sure we have a clear integration strategy for pants first - will revisit soon.

@dan-blanchard - we like this feature. Wondering when would you merge this?

@kramasamy, it's out of my hands at this point. I don't have much time to dedicate to this anymore, and the conflicts introduced by #394 getting merged before this are more complex than I can handle on my own.

I was hoping for a second unbiased opinion or some compromise to tie-break the unresolved "options design" stalemate in this PR, but assuming that isn't going to materialize I think we should figure out a path forward in the name of progress as this seems to be a pain point for several users.
My view is still that overloading --platform here with an alternate extended form is the most ideal from a UX and integration standpoint. pex != pip, so we really shouldn't be striving to exactly replicate pip's UI - but instead do what makes the most sense for the project itself and it's consumers. I've actually never been a fan of the options split/ergonomics as used by pip which this PR gleans from and would be less than thrilled about forklifting that directly into pex.
With that said, I had eagerly landed #394 to improve the pex + bazel integration story while also hoping to force the issue a bit here so that the union of these two changes would make the design challenge more apparent. Since this was my doing, I'd be happy to do the remaining work to carry this PR over the finish line if we can just agree on a strategy for that.
So in the interest of progress, how would you feel about starting with an overloaded form of --platform as the primary interface to this change? Then, if after some experimentation we decide that that API is just too ergonomically terrible for whatever reason, we can revisit adding the single-shot options split as a separate PR?
If that works, I could likely get something out in the next couple of days.

@kwlzn - fine with us.

@kwlzn I'm fine with making the overloaded --platform the primary interface. At this point, I'd just like to have this functionality.

echoing @dan-blanchard comments. Would be nice to to see this feature in action :)

I thought I'd drop an alternate idea, which is to create a new argument name (e.g. --qualifier or --facet...) so that we don't overload the --platform argument.
--platform foo --platform bar would be equivalent to --qualifier foo-any-any-any --qualifier bar-any-any. --platform and --qualifier could potentially be mutually exclusive, but not necessarily.
This approach has the disadvantage of creating a new option, but on the other hand, does not overload the --platform argument and does not break as many ties with pip and hence might be more future-proof.

Is there any chance of getting this one anytime soon?
Thanks!

Any chance of seeing this happen anytime soon? It'd be a really great feature to have.

I've forked and extended this PR over at https://github.com/pantsbuild/pex/pull/399 and it's mostly there but I've unfortunately run of out of time to devote to this for the moment. if someone wanted to help carry #399 over the finish line, that'd be helpful.

@kwlzn, I fixed all the merge conflicts, got rid of the extra command line args, overloaded everything into the platform string (like manylinux1-x86_64-36-cp-cp36m), made the ID_PY interpreter identification bits reuse the new pep425tags code for increased accuracy and consistency, and made the test failures more informative—I was seeing weird failure while fixing the conflicts which were impossible to address without passing -vvvv to the pex command.

@dan-blanchard @kwlzn After Dan's fixes, any additional work that needs to be done for this pr(other than testing to make sure that it works)?

All the tests pass when I run them locally with tox, so I'm not sure what's causing the failure on Travis. 3.3 is failing in a really weird way, but 3.3 was end-of-lifed at the end of September, so maybe that's okay.

@dan-blanchard - Wondering if this is ready to be merged?

@dan-blanchard - also some docs about how to use it will be nice.

@dan-blanchard - i tested this PR to build pex files in mac and run in ubuntu 14.04. I used the producer_tutorial.py and consumer_tutorial.py examples in https://github.com/streamlio/pulsar-python-tutorial
For compiling pex files, I used bazel rules for pex from https://github.com/streamlio/bazel_rules_pex
where I modified PEX_SRC in pex/pex_rules.bzl to use your branch locally. I was able to compile the producer_tutorial and consumer_tutorial successfully using the following bazel rules
pex_binary(
    name = "consumer",
    srcs = ["consumer.py"],
    platforms = [
        "manylinux1_x86_64-27-cp-cp27m",
        "macosx_10_12_intel-27-cp-cp27m",
    ],
    reqs = [
        "pulsar_client",
    ],
)

pex_binary(
    name = "producer",
    srcs = ["producer.py"],
    platforms = [
        "manylinux1_x86_64-27-cp-cp27m",
        "macosx_10_12_intel-27-cp-cp27m",
    ],
    reqs = [
        "pulsar_client",
    ],
)

When I unzip the pex files created, I do find the pulsar_client for both the platforms manylinux1 and macos as shown here
ls -al
total 32
drwxr-xr-x 5 root root 4096 Oct 21 17:29 .
drwx------ 7 root root 4096 Oct 21 17:29 ..
drwxr-xr-x 4 root root 4096 Oct 21 17:29 .bootstrap
drwxr-xr-x 4 root root 4096 Oct 21 17:29 .deps
-rw-r--r-- 1 root root  568 Oct 21 10:04 PEX-INFO
-rw-r--r-- 1 root root  737 Oct 21 10:04 __main__.py
-rw-r--r-- 1 root root  917 Oct 21 10:04 __main__.pyc
drwxr-xr-x 2 root root 4096 Oct 21 17:29 examples
root@57f53c09120c:~/t# ls -al .deps
total 16
drwxr-xr-x 4 root root 4096 Oct 21 17:29 .
drwxr-xr-x 5 root root 4096 Oct 21 17:29 ..
drwxr-xr-x 3 root root 4096 Oct 21 17:29 pulsar_client-1.20.0-cp27-cp27m-macosx_10_12_intel.whl
drwxr-xr-x 3 root root 4096 Oct 21 17:29 pulsar_client-1.20.0-cp27-cp27m-manylinux1_x86_64.whl
root@57f53c09120c:~/t# ls -al .deps/
total 16
drwxr-xr-x 4 root root 4096 Oct 21 17:29 .
drwxr-xr-x 5 root root 4096 Oct 21 17:29 ..
drwxr-xr-x 3 root root 4096 Oct 21 17:29 pulsar_client-1.20.0-cp27-cp27m-macosx_10_12_intel.whl
drwxr-xr-x 3 root root 4096 Oct 21 17:29 pulsar_client-1.20.0-cp27-cp27m-manylinux1_x86_64.whl

I compile the pex in MacOS X and trying to run in ubuntu14.04 docker container.  When I run it, I get the following error -
./producer_tutorial.pex
Failed to execute PEX file, missing compatible dependencies for:
pulsar-client

Wondering what I am doing wrong?

@dan-blanchard - additional data point. I compiled the pex files in ubuntu14.04 and tried to run in ubuntu14.04 itself and I get the same error
./producer.pex
Failed to execute PEX file, missing compatible dependencies for:
pulsar-client

@dan-blanchard - made it work. The key change is to use 'mu' instead of 'm'
"manylinux1_x86_64-27-cp-cp27m",

"manylinux1_x86_64-27-cp-cp27mu",

and it works. Compiled on a mac and ran it in ubuntu.

@dan-blanchard - tried several tests, included several platforms
 "manylinux1_x86_64-27-cp-cp27m",
 "manylinux1_x86_64-27-cp-cp27mu",
 "manylinux1_x86_64-33-cp-cp33m",
 "manylinux1_x86_64-34-cp-cp34m",
 "manylinux1_x86_64-35-cp-cp35m",
 "manylinux1_x86_64-36-cp-cp36m",
 "macosx_10_12_intel-27-cp-cp27m",
 "macosx_10_12_x86_64-36-cp-cp36m",

ran in macosx, ubuntu14.04, centos7 and tried with python2.7 and python3.5 - with single compiled pex and it works!

@kramasamy I think this is good to go, but it would be nice to know why that test fails only on Travis. I've added the docs you requested and made that Failed to execute PEX file, missing compatible dependencies for message more informative so it actually tells you the --platform you're running on so you can make sure it matches with what you generated things for.

One issue that is currently present in this branch is that it does not appear to handle version-specific requirements, like 'enum34; python_version < "3"'. If you try to build a PEX for cryptography using Python 3 that targets 2.7, you'll find the PEX is missing those. Something somewhere is using the current interpreter that shouldn't.

@dan-blanchard - for improving the error message - it is a great help. I am not an expert in the pex code. If some experts like @kwlzn or @jsirois can provide some idea where to look, I am happy to fix.

I managed to track the issue down. Turned out to require another bit of monkeypatching because they were being filtered out inside pkg_resources/packaging.

@dan-blanchard - nice work!

The REPL test failures are now reproducible in the sense that I can also get them by running tox, but not in the sense that running the exact same command from my virtualenv does not cause a failure.

@dan-blanchard - any luck in fixing the travis issue?

@kramasamy No, I think one of the maintainers will have to poke around for that. I had some time to dedicate to this again, but I'm busy with other things again. I also feel like it is going to take me much longer to figure out than one of the maintainers.

So is this PR dead again?

@kwlzn @dan-blanchard a lot of effort has been invested in this work (can't thank you enough for that) and it looks like we're almost there, plus there seems to be a lot of interest from pex users, which makes me think getting this over the finish line could be worth the investment! wdyt? :-)

Rebased to fix conflict again.

ALL THE TESTS PASS NOW.

Oh joy, more conflicts to fix. 😭

Okay, conflicts fixed again. All tests still pass.

Please, please, please can we get this merged? It not being released is holding up things and forcing us to use a branch when we should be able to use a released version of PEX. It's there, tests pass, and it works. I get the maintainers don't need this use case, but clearly several users do.

Since there are many other users like ourselves who need this feature, we've gone ahead and forked pex. manypex is available on PyPI. The only difference between it and 1.3.2 is the addition of this manylinux PR. We try to keep things in sync with pex as new versions come out for as long as it takes to get this functionality into mainline pex.
Also, note that the distribution name is different, but the package and CLI names did not change. That way you don't need to change anything about your workflow to use it.

@dan-blanchard thanks for this, though it's a pity you had to resort to a fork. It's still not clear to me why this PR hasn't been merged into upstream yet. Is it just lack of interest or are there any outstanding issues that haven't been addressed?
cc @kwlzn

@stuhood that's good, thank you for the reply! Enjoy your break :)

good news and bad news here.
the bad news: it turns out that #461 has been silently masking test failures in master for several weeks now. as a result, this PR (and transitively, the manypex fork), have active test failures/breakage that is revealed if you drill into the output of individual test shards.
the good news: I've got the changes from #399 retrofitted on top of this PR, which include fixes for the failing tests and other breakage.
we're working through #461 and the underlying master failures now. once master is green again, the plan is to land this PR as-is (breaking master) and then fast-follow with the #399 retrofit (repairing master). I'll post the #399 retrofit PR for review soon (as a separate PR). but please avoid any pushes to this PR in the meantime.
but beyond that, we're hoping to cut the first official pex release with manylinux support (likely pex 1.4.0) soon! thanks for the patience and perseverance on this and in particular to @dan-blanchard and team.

the final, combined manylinux implementation is now reviewable here: #480

this and #480 are now in and released via pex 1.4.0 on pypi.
I added a quick usage blurb here: https://github.com/pantsbuild/pex/issues/281#issuecomment-389352166
please take a moment to kick the tires on this new release and file any issues you might find. enjoy!


Overflow on the Curriculum lessons container

There's an overflow in the Curriculum lessons container that's caused by the CSS property flex: 0 0 100%; on the element with the class of curriculum_child-scroll__3g0eX

Removing the property overflow: auto!important; and replace it with overflow: hidden; should fix it.

Replacing overflow: auto with hidden will break the swipe feature on mobile devices: https://github.com/garageScript/c0d3-app/pull/825#issuecomment-850266145
Currently, the scrollbar only appears in Brave.

No need to close this, scrollbar is still there.


[embedded] Mark embedded/classes-indirect-return.swift test as 'REQUIRES: OS=macosx || OS=linux-gnu'

To resolve a CI failure: https://ci.swift.org/job/oss-swift_tools-RA_stdlib-DA_test-device-non_executable/6077/console
rdar://126878901

@swift-ci please smoke test


Update sbt-microsites to 1.4.1

Updates com.47deg:sbt-microsites from 1.2.1 to 1.4.1.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.47deg", artifactId = "sbt-microsites" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "com.47deg", artifactId = "sbt-microsites" }
}]

labels: sbt-plugin-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #81.


route not working

while on windows 10, and using 1.3.0 all functions works perfectly except for routes. it displays the following
https://i.gyazo.com/d7a14f8686e63d314c3270ac6dcb0cc0.png

+1, I'm pretty sure it worked in 10.97 and stopped working on 10.98, at least for me.

this happens to me too at 1.4.2 running tibia 11 windows 10


writing-mode

writing-mode

This issue was imported from Google Moderator
Moderator votes: +8
Issue added by Frank on 2012-02-11
To vote this issue up or down, simply include +1 or -1 in your comment.

Duplicate of #996 so adding half the votes there


TypeError: 'MultiPoint' object is not iterable

When I run the code in Jupyter Book, I encounter the following issue. How can I resolve it? I didn't modify any of the code

RemoteTraceback                           Traceback (most recent call last)
RemoteTraceback:
"""
Traceback (most recent call last):
File "/opt/conda/envs/SpotGF/lib/python3.7/multiprocessing/pool.py", line 121, in worker
result = (True, func(*args, **kwds))
File "/opt/conda/envs/SpotGF/lib/python3.7/multiprocessing/pool.py", line 47, in starmapstar
return list(itertools.starmap(args[0], args[1]))
File "/deep/SpotGF-main/SpotGF.py", line 134, in calculate_ot
gene = []
File "/opt/conda/envs/SpotGF/lib/python3.7/site-packages/alphashape/optimizealpha.py", line 100, in optimizealpha
if _testalpha(points, test_alpha):
File "/opt/conda/envs/SpotGF/lib/python3.7/site-packages/alphashape/optimizealpha.py", line 41, in _testalpha
return all([polygon.intersects(point) for point in points])
TypeError: 'MultiPoint' object is not iterable
"""
The above exception was the direct cause of the following exception:
TypeError                                 Traceback (most recent call last)
/tmp/ipykernel_163981/864656051.py in
14
15 ##
---> 16 GF_df = spotgf.calculate_GFscore(gem_path, binsize)
...
--> 657             raise self._value
658
659     def _set(self, i, obj):
TypeError: 'MultiPoint' object is not iterable
Output is truncated. View as a scrollable element or open in a text editor. Adjust cell output settings...
Thanks!!!

Thank you, lowering the version can solve the problem

Thank you, lowering the version can solve the problem

Hello,
I got the same error. May I ask which version that you used that can solve the problem?
Thanks for your help.
Weijia

Thank you, lowering the version can solve the problem

Hello,
I got the same error. May I ask which version that you used that can solve the problem?
Thanks for your help. Weijia

I use shapely==1.8

I use the following environment is not reported error, you can try it. I hope you try the new version of SpotGF, i have updated it~
python==3.9.19
numpy==1.23.5
pot==0.8.2
pandas==1.4.0
matplotlib==3.5.0
scipy==1.10.0
descartes==1.1.0
alphashape==1.3.1
shapely==1.8.5.post1
scanpy==1.9.2
seaborn==0.13.2


Update relationships to work better with future ancestry

Ancestry will no longer support condition clauses (Model.where(Model.child_conditions))
Instead, basic active record where clauses are used (Model.children)
this changes our condition clauses to instead use basic AR where clauses
After this, we will be able to upgrade to ancestry 2.0 in https://github.com/ManageIQ/manageiq/pull/20508
/cc @agrare

sorry about that, fixed the tests

fixed cop


*: Skip printing stracktrace when using panic::recover

@ngaut @siddontang

can using set_handler do this too? I think it is more clear and easy.
https://github.com/rust-lang/rust/issues/30449

set_hook is formerly called set_handler. :)

LGTM

@ngaut PTAL

LGTM


feat: Add github action to create helm chart index

Summary of Changes
Add github action to create helm chart index published on gh-pages
branch. One could then install amundsen helm chart like so:
helm repo add amundsen https://amundsen.io/amundsen
helm install amundsen

Tests

Would need to release to branch in order to fully test. You can compare to https://github.com/coredns/helm to see an example of this gh workflow.
edit:
tested on fork of repo. Chart published to gh-pages branch and can be seen at https://mhumesf.github.io/amundsen/index.yaml
Documentation

CheckList
Make sure you have checked all steps below to ensure a timely review.

[x] PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"

In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

[x] PR includes a summary of changes.
[x]  PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
[x] In case of new functionality, my PR adds documentation that describes how to use it.

All the public functions and the classes in the PR contain docstrings that explain what it does

Anything else needed for this?

this looks correct. @mgorsk1 could you take another look in case I miss anything?

Does it mean we need to reserve gh-pages branch solely for helm index?

does it mean we need to reserve gh-pages branch solely for helm index?

No, just a place for index.yaml to be resolvable. For example https://mhumesf.github.io/amundsen/ is still working, as well as https://mhumesf.github.io/amundsen/index.yaml

maybe we should have separate on release action (like we do for other microservices) instead of running this with every merge to main? Otherwise we have misalignment in release logic

This bit below will make it so only take action when files are modified in the helm directory. Chart-releaser does publish a release title amudsen-. You can see that here https://github.com/mhumeSF/amundsen/releases/tag/amundsen-2.1.1. Maybe it'd be better to publish the release as admundsen-helm-2.1.1 with other releases. But again, the github workflow will only trigger when files in the path 'amundsen-kube-helm/templates/**' are updated and will only release when the chart version in Chart.yaml is bumped higher.
on:
  push:
    branches:
      - main
    paths:
      - 'amundsen-kube-helm/templates/**'

I assume the version of the chart is taken from Chart.yaml? What happens if version is not bumped but new merge to main happens? Does the same version gets overwritten with different chart contents?

In the case where files in the helm chart are modified, but no chart version is bumped, the github action is triggered but will error because it will try to upload using a tag that already exists.

I would also document it so users are aware of it cause it's not obvious that we provide helm index.
I'll add to PR updates to documentation.

After some investigation, It look likes mkdocs will remove any files published on gh-pages not related to docs dir. This means the published index.yaml file gets removed when docs are republished. I'll have to look into mkdocs to see if there is a way to skip/overlook index.yaml from getting destroyed.

@mgorsk1 Haven't found anything. I'm going to close for now. I'll open a new PR if I find a simple way to do this.


Sources

Hii there I used this scraper and it was good but it will be more better if you please provide option to manually add sources for proxies.
Like different sources files http,socks4,socks5 so that we can have more proxies from our own desired url/website.
Please look into this.

why don't you add a regex for ip:port instead, saves you the trouble.

why don't you add a regex for ip:port instead, saves you the trouble.

Because I'm not just good at regex, :D kidding, but having a well-structured scraper is better than just using regex in my prospective. Regex is my last solution always. Do you think regex is a better option?

Well, sure why not? it can barely mess with your well structured code as it only consists of 5-6 lines of extra code (for simpler terms), without requiring any fancy structuring to the code.

Can be a good solution, but I have to test it. If you have time you can do a sample on your fork maybe? And we can check the time for doing benchmarks.

sure thing, I'll let you know once i have done it

Thank you!


NULL values for Parquet data types

What are explicit NULL value definitions for Parquet data types?
For example, here is a modified patch from arrow/cpp/examples/parquet/low-level-api/reader-writer2.cc
      parquet::Int32Writer* int32_writer =
             static_cast<parquet::Int32Writer*>(rg_writer->column(col_id));
      /* ? For int32_t null value I would expect something like -2147483648 */
      int32_t int32_value = parquet_int32_null_value_definition;
      int32_writer2->WriteBatch(1, nullptr, nullptr, &int32_value);

Parquet nulls are represented using definition levels only -- i.e. "0" is a null, "1" is a non-null, for a simple OPTIONAL non-repeated field. If you have more questions can you write to<EMAIL_ADDRESS>or<EMAIL_ADDRESS>


Depend on aesara-base instead of aesara

Blocking https://github.com/conda-forge/pymc-feedstock/pull/49

Checklist

[X] Used a personal fork of the feedstock to propose changes
[X] Bumped the build number (if the version is unchanged)
[X] Reset the build number to 0 (if the version changed)
[X] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[X] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

Warning
This has the unfortunate side-effect going forward of effectively pinning aesara >=2.7.4 since the aesara-base package doesn't exist otherwise.
Note that build 0 will still be solvable even after build 1 becomes available. Thus conda install -c conda-forge aeppl aesara<2.7.4 will still work and install aeppl 0.0.31. But once 0.0.32 comes out, the above command will only continue to work with 0.0.31.
Is this a problem?

Or should we adopt the dual-output model here as well? (aeppl-base + aeppl)

Or should we adopt the dual-output model here as well? (aeppl-base + aeppl)

I think that's the only way, otherwise people who'd just install aeppl wouldn't get compilers :-/.

Superseded by #30


Escape every string before output

Whether malicious or accidental, not escaping strings before outputting them to the feed opens the door for a user to totally bork their feed.
This pull request tries to escape everything that might be a string before outputting to the feed.

Nice. And a test! Thanks again for the pull request.


istioctl profile should be relative to the default

Right now if I run istioctl profile {diff,dump} it is outputing a huge amount of info since it is related to the default profile. It should be able what is changed since the default
For example, istioctl profile dump should show:
apiVersion: install.istio.io/v1alpha2
kind: IstioControlPlane
spec:
  security:
    components:
      nodeAgent:
        enabled: true
  values:
    global:
      controlPlaneSecurityEnabled: true
      mtls:
        enabled: true
      sds:
        enabled: true
        udsPath: "unix:/var/run/sds/uds_path"
        token:
          aud: "istio-ca"
    nodeagent:
      image: node-agent-k8s
      env:
        CA_PROVIDER: "Citadel"
        CA_ADDR: "istio-citadel:8060"
        VALID_TOKEN: true

Similarly, diff should probably just show the above, not 1000 lines of all the default stuff. Its not even accurate if you say ik profile diff sds default since it doesn't account for the fact that sds is applied above default.

I am not sure what's the issue of dumping complete ICPS, including configs in default profile. Users are supposed to use profile diff to compare the differences. Can you elaborate?
But I also found an issue related: https://github.com/istio/istio/issues/19692

the ICP is like 1000 lines, nobody understands that. The only thing they want to see is that the SDS profile adds these 6 fields or whatever.
I guess if diff is fixed so it only shows those 6 lines changed its fine, but I can't imagine anyone ever wanting to dump the full profile.

This may be more of a documentation issue, since profile dump/diff are not extensively documented. For dump, there's a -p/--config-path flag which lets the user dump out just the subtree they are interested in e.g. -p trafficManagement.components.pilot.k8s.
To see how profiles differ, you'd use profile diff. e.g. istioctl profile diff ./profiles/default.yaml ./profiles/sds.yaml. This only supports files now so you need some gyrations - it may be worth considering supporting profile names in this command.

I think you can do ik profile diff default sds, but if you try it you
will see its broken
On Thu, Jan 2, 2020 at 4:33 PM Martin Ostrowski<EMAIL_ADDRESS>wrote:

This may be more of a documentation issue, since profile dump/diff are not
extensively documented. For dump, there's a -p/--config-path flag which
lets the user dump out just the subtree they are interested in e.g. -p
trafficManagement.components.pilot.k8s.
To see how profiles differ, you'd use profile diff. e.g. istioctl profile
diff ./profiles/default.yaml ./profiles/sds.yaml. This only supports files
now so you need some gyrations - it may be worth considering supporting
profile names in this command.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/19552?email_source=notifications&email_token=AAEYGXJ4Y7GHBYTC6NW3KXLQ32BWLA5CNFSM4J2C4WW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH75SDA#issuecomment-570415372,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXJTRGDJFKN7ZFSZVV3Q32BWLANCNFSM4J2C4WWQ
.


Being Told JavaScript Object Function Definition Pnly Allowed In Typescript In Error

Does this issue occur when all extensions are disabled?: Yes

VS Code Version:

Version: 1.89.1
Commit: dc96b837cf6bb4af9cd736aa3af08cf8279f7685
Date: 2024-05-07T05:16:23.416Z
Electron: 28.2.8
ElectronBuildId: 27744544
Chromium: 120.0.6099.291
Node.js: 18.18.2
V8: 12.0.267.19-electron.0
OS: Linux x64 6.5.0-35-generic

OS Version:   Ubuntu 22.04.4 LTS

Steps to Reproduce:

Create Javascript functions in inside a js object with function arguments with assign default values.
.

This Is NOT An Error!

Please share a complete, self contained code example as text

Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our issue reporting guidelines. Please take the time to review these and update the issue.
Happy Coding!


fix(ui): add end of string to build regex to prevent unwanted matches

Fixes issue #1629, pasted below:
What problem does this feature solve?
The match regex in @vue/cli-ui/ui-defaults/tasks.js doesn't have an end of string modifier at the end of it ($). This means it matches vue-cli-service build:electron or something else similar. Since these defaults overwrite plugin ui config, this prevents developers like me for making their plugin work with the ui.
What does the proposed API look like?
Add $ to the end of the match regex for the build/serve commands. Created pr #1630 which does exactly this.

Thanks! Closing since I fixed the issue differently.


RTR TowerBag

RTR Towerbag. Last one, I swear!

Some files are missing no? I don't see the gmloader and the libs 🙃

Some files are missing no? I don't see the gmloader and the libs 🙃

Those are already in existing release, I was under impression I am to only submit changed / new files? Do I get it wrong?

Oh my bad, I have missed that ! Sorry 😅


Include documentation of new code base

Signed-off-by: Elly Kitoto<EMAIL_ADDRESS>IMPORTANT: Where possible all PRs must be linked to a Github issue
Fixes #[issue number]
Type
Choose one: (Bug fix | Feature | Documentation | Testing | Code health | Release | Other)
Checklist

[ ] I have written Unit tests for any new feature(s) and edge cases for bug fixes
[ ] I have added any strings visible on UI components to the strings.xml file
[ ] I have updated the  CHANGELOG.md file for any notable changes to the codebase
[ ] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the project's style guide
[ ] I have built and run the fhircore app to verify my change fixes the issue and/or does not break the app

Pull Request Test Coverage Report for Build #409

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 43.918%

Totals

Change from base Build #400:
0.0%

Covered Lines:
278

Relevant Lines:
633

💛  - Coveralls


fix(package_info_plus): fixed deprecation warning & updated dependencies

Description
This PR removes the deprecated embedding V1 from package_info_plus. Besides that it updates the dependencies and fixes a deprecation issue with regards to getBuildSignature method.
Related Issues
Probably fixes #301
Checklist

[X] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[X] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[X] All existing and new tests are passing.
[X] I updated/added relevant documentation (doc comments with ///).
[X] The analyzer (flutter analyze) does not report any problems on my PR.
[X] I read and followed the Flutter Style Guide.
[X] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
[X] No, this is not a breaking change.

I just updated main branch can you please  update with main. and then let's merge your branch.

I just updated main branch can you please update with main. and then let's merge your branch.

I will but before merging, should we remove the deprecated registerwith function, or just leave it in and annotate so it hides the warning? Because whatever we chose, we should apply it to all other packages aswell.

Well, I'd say if we have a solution to replace it with a new API, let's do that, that much better, however, if we don't lets at least annotate it so later we will remove depreciated API and replace them with a new one.
I prefer to implement a new API if possible.

Currently v1 embedding with registerWith is only kept for backwards compatibility. However it seems that it isn't included in new releases according to official Flutter documentation. So i'd say it's safe to remove it.

@juliansteenbakker
It is my understanding that it is good to keep the registerWith() method to remain compatible:
Also, note that the plugin should still contain the static registerWith() method to remain compatible with apps that don’t use the v2 Android embedding. (See Upgrading pre 1.12 Android projects for details.) The easiest thing to do (if possible) is move the logic from registerWith() into a private method that both registerWith() and onAttachedToEngine() can call. Either registerWith() or onAttachedToEngine() will be called, not both.
https://flutter.dev/docs/development/packages-and-plugins/plugin-api-migration#upgrade-steps
@mhadaily
I added PRs that suppress the build warnings for all remaining packages. Didn't see that for package_info_plus there is already this one. I can close mine probably?

@nohli It's more a question of choice i think. The flutter team encourages everyone to upgrade to V2, and right now only 20% of the projects use V1. You can keep providing support for V1 but where are you going to draw the line? Besides that, is it even possible for Flutter applications that only support V1 embedding to also support null-safety, like all packages here does?

@nohli You can close your pr for this package. I'll update this to leave the registerWith in it if thats what we're deciding.

@nohli @juliansteenbakker let's discuss there and make a decision, I don't think it's very critical to support V1. what we can do we can remove this and release a new Major version for packages so if anyone likes to use older version so still, they can but we will not support it?
what do you think?
question for you @nohli  if you think this PR is covering your PRs, let's close yours and focus on this one if you agree?

@juliansteenbakker build failed, I think you need to rebase with main

Already closed.
So you want me to close all the other PRs, and open a new one, removing the registerWith method, for all other packages?

I am not still sure if removing registerWith() is a correct way of doing it. however, if we release a new Major version, it won't break people's code.
btw, since this change is fairly similar for all packages, I'd like to have one PR covering the same thing for all packages instead of several PRs.
just in case if we got any problem, I can revert one commit and it works for all packages at the same time.
What's your opinion @nohli and @juliansteenbakker ? I'd like to know your opinion too.

What's your opinion @nohli and @juliansteenbakker ? I'd like to know your opinion too.

In my opinion i think it's good to just delete them. People using embedding v1 should upgrade, even the Google documentation says so. This in combination with new plugins being created without embedding v1 is enough reason for me to remove it.
I can however understand that other people would keep embedding v1 in 'just in case' and i think it's a valid point, but it's just not my opinion.

As discussed in #461 i've deleted the v1 embedding once again and bumped the version number.
Currently blocked by #489

@juliansteenbakker PR is merged.
btw, since we have now this PR https://github.com/fluttercommunity/plus_plugins/pull/495 do you think your PR will be still valid?

btw, since we have now this PR #495 do you think your PR will be still valid?

Yes because that PR doesn't contain changes for package_info_plus. Also, this PR solves other deprecation problems besides embedding V1.

@mhadaily this is ready to be merged

@juliansteenbakker could you also use 30 for compileSdkVersion and targetSdkVersion?
31 is Android 12 which is still in beta.

31 is Android 12 which is still in beta.

It is not in beta since yesterday, but I would be careful with pushing to 31, because it has some behavior changes. For example, android_alarm_manager should be upgraded carefully, considering this change https://developer.android.com/about/versions/12/behavior-changes-12#exact-alarm-permission
Haven't checked if other packages would need the same though

@nohli Android 12 is not in beta anymore. Besides, when a new number is available in compileSdkVersion, it means that the API is stable. Otherwise it would be marked as such: compileSdkVersion 'android-R'. compileSdkVersion 31 has been stable since 14 July.

31 is Android 12 which is still in beta.

It is not in beta since yesterday, but I would be careful with pushing to 31, because it has some behavior changes. For example, android_alarm_manager should be upgraded carefully, considering this change https://developer.android.com/about/versions/12/behavior-changes-12#exact-alarm-permission Haven't checked if other packages would need the same though

We should migrate and check every package individually. That is why this PR is only about package_info_plus.

We should migrate and check every package individually

Yes, agree here. My message was mostly to @nohli since he has one big PR with changes to multiple packages, so I wanted to bring attention to that moment about Android 12.


feat: Pass hit reslut to event

Because events fired in object space, we can't use a PointX, PointY as World coords from event.
For resolve this lib shoud use a IntersetectMeshes  instead of InterectBounds and include a mesh hit result to event data.
See:
https://github.com/oframe/ogl/blob/master/src/extras/Raycast.js#L129
https://github.com/oframe/ogl/blob/master/src/extras/Raycast.js#L232
We can use a flag for selecting which is mode should be used for tracking events, because not always required a strict recognition, but i not shure how this can be selected object-specifically in event phase.
Demo is changed too.

Another way: we can set hit field in loop when call events and pre-mix interface for Event type, but this is dirty way and hit will be mutated for each node with same Event.

Looks good. Eventually, I'll want to move to use what's currently R3F's events system (they have this raycaster config sorted out), but it's still connected to that library. Interop with threejs doesn't look easy, so having our own events is fine for now.


refactor!: remove Partial

Pull Request Test Coverage Report for Build<PHONE_NUMBER>2
Details

20 of 20 (100.0%)  changed or added relevant lines in 2 files are covered.
3 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.02%) to 96.015%

Files with Coverage Reduction
New Missed Lines
%

src/Object.ts
3
95.76%

Totals

Change from base Build<PHONE_NUMBER>7:
-0.02%

Covered Lines:
1232

Relevant Lines:
1278

💛  - Coveralls


How do i format number when export to xls?

I need to format number like 12345.6789 into 12,345.68, and display as number in excel - not display as text in excel. Or else, some excel functions like filter, sorting won't work properly.
I did read example here: https://github.com/agershun/alasql/wiki/XLS, but couldn't figure out a way to format number in excel.
E.g. if the number is in text, sorting would be like
.
.
.
1.98
1.99
10.00
.
.
.
2.00
.
if sorting number instead of text, it should come as:
.
.
.
1.98
1.99
2.00
.
.
.
10.00
.
.
.
Thanks in advance!

This is same problem as #651
I will close this issue an look for updates in the other tread...


Add a draw.io version of the diagrams

Hi -
On this commit:
aks-regulated-baseline.drawio - This file contains a copy of the diagrams used throughout the baseline document. You can edit it and change it to your particular scenario using http://draw.io/
aks-regulated-baseline-Network Topology.svg and ask-regulated-baseline-Workload HTTPS request flow.svg are samples exports from the draw.io file.
Since this is editable, would allow folks to change these files and adapt to their solution.
ok? comments?
-dcasati

Thanks @dcasati!


Auto generate .gitlab-ci-local/.gitignore file If .gitignore file isn't git add'ed right away, make sure .gitlab-ci-local is excluded from rsync

@bcouetil @JoyceBabu
I was able to reproduce, when ever .gitlab-ci-local/.gitignore wasn't manually git add'ed, the recursive behavior occurs.

I came to say that I easily reproduced also :smile:

Tested this branch, working like a charm :muscle:

@bcouetil Approve, lets get it right in :smile:

@firecow Great. Usually when you add a gitignore file with content '*, you won't be committing the file (unless you want to create an empty directory). So, the PR is useful. But now I think it is safe to exclude the entire .gitlab-ci-localdirectory, not just.gitlab-ci-local/builds/${target}`.


MockPin and MockPWMPin documentation missing

Any reason MockPin and MockPWMPin are left out of the pins page in the docs?
It's a shame these are not documented - we should ensure they are included. We should show people the API docs for these classes, and give the environment variables requires to use them by default - and state that they are cross-platform and ideal for testing code on a PC.

@waveform80 perhaps we can nudge this into 1.4?

I've added a section to the #569 PR - what do you think? I can't add them directly into the table because that's also what defines the fallback order of pins (and mock isn't in that order, nor should it be), but I've added a section detailing them with a chunk of example code. I've also moved the "Utilities" section into its own chapter as it's rather important, but it was really getting buried at the end of a (now) very long chapter.


Extend and improve "How to use schema" addressing DOC-1337

Contributions: We are not currently taking public contributions - see our contributions policy. However, we are accepting issues and we do want your feedback.

DOCUMENTATION TICKET
Description
Address the ticket DOC-1337 by adding content to introduce CookAndGenerateSchema commandlet and make general page improvements while on the page
Primary reviewers
If your change will take a long time to review, you can name at most two primary reviewers who are ultimately responsible for reviewing this request. @anne-edwards @mattyoung-improbable

Shit, this is the wrong branch. Apologies.


Add user wallet history endpoint

https://www.bitmex.com/api/explorer/#!/User/User_getWalletHistory

Done. 😄

🦅 🥇


Adding http version and streaming info to logging output

Final part of #600

Can you show what the new log output looks like now? I don't think Version.ToString formats the way you want by default. You can borrow GetHttpProtocol: https://github.com/dotnet/aspnetcore/blob/393a86c0e7218964e557adeb833010e1482bb96b/src/Http/Http.Abstractions/src/HttpProtocol.cs#L112 And put it here:
https://github.com/microsoft/reverse-proxy/blob/2015d992e0061c6849fbe11c62311161b3399210/src/ReverseProxy/Forwarder/ProtocolHelper.cs#L9

Current output:
info: Yarp.ReverseProxy.Forwarder.HttpForwarder[9]
      Proxying to http://www.example.com/ - http2.0 RequestVersionOrLower no-streaming

How exactly do we want it to read? Options:

 Proxying to http://www.example.com/ - HTTP/2 RequestVersionOrLower no-streaming

 Proxying to http://www.example.com/ - http2 ≤  false

 Proxying to http://www.example.com/ - http≤2  no-stream

 Proxying to http://www.example.com/ - HTTP/2 RequestVersionOrLower no-streaming

Looks good.


get rid of class cast exception and add a new testcase for that issue

Fixes error Sanitization issue for non sanitizable exceptions.
QueryInterruptedException when sanitizes itself creates a QueryException so need to cast to to return a valid RuntimeException

Description

Key changed/added classes in this PR

ErrorHandler

This PR has:

[X] been self-reviewed.

[ ] using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)

[ ] added documentation for new or modified features or behaviors.
[ ] added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
[ ] added or updated version, license, or notice information in licenses.yaml
[ ] added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
[X] added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
[ ] added integration tests.
[X] been tested in a test Druid cluster.

The other modules tests have been failing in other PRs and looks unrelated to this change.Here are a couple of examples where it is failing.
I think it is ok to overrule travis in this instance and merge this PR


Fix cert-manager config for private clusters

Please check if PR meets these requirements

[ ] Results of the diffs have been examined and no unintended changes are being introduced.

Helper

to disable the GH Action generating manifests diffs for installations, between target and source branches, comment the /no_diffs_printing on the PR.

Trigger e2e tests

/run cluster-test-suites

Added to https://github.com/giantswarm/cluster-azure/pull/300


[BUG] Gadget tester throwing polynomial degree errors on negative tests

If gadget_tester is used to go through proof generation/verification of a circuit that is satisfied it will work with a maximum polynomial degree that corresponds to the circuit size.  However if the same circuit is instantiated in an incorrect way, like in a failure test, then the gadget_tester will throw a Polynomial Commitment Error: TooManyCoefficients.
There's a minimal example of this here.  The negative test should fail on an Error::ProofVerificationError but instead fails on the above Polynomial Commitment Error.  This can be remedied by increasing the padded_circuit_size (here) from 1 << 2 to 1 << 4.
It is unclear how "dangerous" this bug is.  Assuming that padded_circuit_size is the right size for a correct circuit, then a negative test using gadget_tester would still detect incorrect circuits with a failure message, just not the one we expected.  Nonetheless it seems worthwhile to understand this better.

Replaced with https://github.com/webb-tools/arkworks-gadgets/blob/master/arkworks-plonk-circuits/src/utils.rs#L89


Above Ground Lakes (Lava  & Water) Partially Frozen

Reported by: @JfromHolland29
I think stuff like that "Objects spawned in a new chunk, but extend to already replaced chunks don't have their blocks replaced in the existing chunk." happens with lava lakes in snow biomes. Often half of them is lava, and half of them is a mix of ice, water, lava, and obsidian...

In Vanilla, Lava lakes don't have a freeze effect. 8b6e59d fixes this and adds the ability to make ALL lakes fully frozen, as well as turn on lava lake freezing. See this post on the forum for more information.


Using .Include() in parent child parent collections gives exception on the second call

The first call works, loading into the cache, but the second call gives an exception.
The exception
The RelatedEnd with role name 's' from relationship 's_c_FK' has already been loaded. This can occur when using a NoTracking merge option. Try using a different merge option when querying for the related object.
I tried to reproduce in a unit test, but sadly i haven't been able to do so :(
        var query = Context.Product
            .Include(x => x.Tags)
            .Include(x => x.Tags.Select(t => t.MainProduct))
            .Cacheable().FirstOrDefault()

Yes, I'm using NoTracking here, because these types of queries are supposed to be read-only and they shouldn't be used for updating or deleting. They are mainly for reporting purposes and they will be disconnected from the context for the second call, because this time, the context will be ignored and the cache would be the source of the entities.
So if you are going to modify the results of the cached queries, it won't work.

I'm not updating entities, i do not want to update them.. but i guess there is an issue with NoTracking when executing queries.
Could you build something to disable the NoTracking for specific queries?

I can't reproduce it. I added a new test method called TestEagerlyLoadingMultipleLevels, which uses multiple level Include methods and it works fine with both EF DB-First and Code-First.

I can only reproduce it in our model, but not in the adventure works model. Sorry, but it would cost me too many story points to go further into this issue. I skipped caching in this specific case. The issue still exists, you could close it if you want.

Issues without a working sample will be closed.


TeamServer error -> Segmentation fault

error log
$ ./TeamServer
[2024-05-14 07:00:57.750875] [0x000070e86ca98cc0] [info]    Team Server listening on <IP_ADDRESS>:4444
[2024-05-14 07:01:27.675115] [0x000070e868bf8640] [info]    AddListener Tcp <IP_ADDRESS>:443
SocketHandler.cpp - initServer: initServer
SocketHandler.cpp - receive: receive
SocketHandler.cpp - sendData: sendData
SocketHandler.cpp - closeConnection: closeConnection
SocketHandler.cpp - initServer: initServer
SocketHandler.cpp - receive: receive
SocketHandler.cpp - sendData: sendData
SocketHandler.cpp - closeConnection: closeConnection
SocketHandler.cpp - initServer: initServer
SocketHandler.cpp - receive: receive
SocketHandler.cpp - sendData: sendData
SocketHandler.cpp - closeConnection: closeConnection
SocketHandler.cpp - initServer: initServer
SocketHandler.cpp - receive: receive
SocketHandler.cpp - sendData: sendData
SocketHandler.cpp - closeConnection: closeConnection
SocketHandler.cpp - initServer: initServer
SocketHandler.cpp - receive: receive
SocketHandler.cpp - sendData: sendData
SocketHandler.cpp - closeConnection: closeConnection
SocketHandler.cpp - initServer: initServer
SocketHandler.cpp - receive: receive
SocketHandler.cpp - sendData: sendData
SocketHandler.cpp - closeConnection: closeConnection
SocketHandler.cpp - initServer: initServer
SocketHandler.cpp - receive: receive
SocketHandler.cpp - sendData: sendData
SocketHandler.cpp - closeConnection: closeConnection
SocketHandler.cpp - initServer: initServer
SocketHandler.cpp - receive: receive
SocketHandler.cpp - sendData: sendData
SocketHandler.cpp - closeConnection: closeConnection
SocketHandler.cpp - initServer: initServer
SocketHandler.cpp - receive: receive
SocketHandler.cpp - sendData: sendData
SocketHandler.cpp - closeConnection: closeConnection
SocketHandler.cpp - initServer: initServer
SocketHandler.cpp - receive: receive
SocketHandler.cpp - receive: receive failed: End of file
SocketHandler.cpp - closeConnection: closeConnection
SocketHandler.cpp - closeConnection: closeConnection
Segmentation fault (core dumped)

I think I found the issue!
I am not setting 'm_socketTcp=nullptr;' int SocketHandler.cpp : Server::closeConnection() after I deleted it!

Should be fixed in the 0.0.2
Thanks for the report!

Fixed ,thanks.


Get function name without arguments

Hi, is there any easy way to get only the functions name without all of the arguments?
Would I have to write my own implementation of TypeFormatter? Please bear with me, I just started with rust...

Oh, huh, I was going to point you to ContextPdbData::make_type_formatter_with_flags and then show you the TypeFormatterFlags for eliminating function arguments... but it looks like there is no NO_ARGUMENTS flag!
I will add one.

I was bored and need to improve my rust knowledge anyways, so I created a pr that adds the wanted functionality. #59

I've released 0.10.3 with the fix.


PyInstaller fails: OSError: PortAudio library not found

I am using sounddevice in my project running on Ubuntu - When I build a single file using pyinstaller it is failing with (The code works well when running the source python file):
Traceback (most recent call last):
  File "Run_SD.py", line 2, in <module>
  File "Smart_Device.py", line 26, in init Smart_Device
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "PyInstaller/loader/pyimod03_importers.py", line 540, in exec_module
  File "sounddevice.py", line 71, in <module>
OSError: PortAudio library not found
[213] Failed to execute script Run_SD

Unfortunately I can't simply apt get install the required portaudio on the machine, so it needs to be included in the package. I have tried adding in the lib using:
--add-binary libportaudio.so:.  --add-binary libportaudio.a:.
But this isn't working. I'm guessing I need to actually import the portaudio library into my python source - is that correct? Any pointers on how to do this?

I fixed this problem by editing:
versions/3.8.5/lib/python3.8/site-packages/_pyinstaller_hooks_contrib/hooks/stdhooks/hook-sounddevice.py
elif is_linux:
    path = os.path.join(
        sfp[0], "_sounddevice_data", "portaudio-binaries", "libportaudio.so"
    )

versions/3.8.5/lib/python3.8/site-packages/sounddevice.py
    elif _platform.system() == 'Linux':
        _libname = 'libportaudio.so'

Then included the libportaudio.so in the pyinstaller build:
--add-binary _sounddevice_data/portaudio-binaries/libportaudio.so:./_sounddevice_data/portaudio-binaries/


jq processing Error

Getting this error while trying to process the Terraform state or plan file with terraform.jq file:
$ terraform state pull | jq -cf terraform.jq
jq: error: ARGS/0 is not defined at <top-level>, line 518:
, if $ARGS.named.extra != null then
jq: error: walk/1 is not defined at <top-level>, line 24:
        walk(if isidle then . elif isiterable then delpaths([paths(isidle)]) else . end);
jq: error: ENV/0 is not defined at <top-level>, line 43:
        fallback_region: ($ENV.AWS_DEFAULT_REGION // $ENV.AWS_REGION // "eu-west-1")
jq: error: ENV/0 is not defined at <top-level>, line 43:
        fallback_region: ($ENV.AWS_DEFAULT_REGION // $ENV.AWS_REGION // "eu-west-1")
jq: 4 compile errors

a workaround is to delete this block from the terraform.jq file.
jq latest 1.5 version
Terraform v0.12.19

Hi @tmxak !
JQ version 1.6 is required for this to work.
https://github.com/stedolan/jq/releases

Please give it a try and comment back if the problem persists.

yeah. you're right. works fine with 1.6 jq version.
For installing jq I was following the official docs for ubuntu. Didn't notice that there is a higher version.. I think it worth mentioning the required jq version for this module. Thanks @antonbabenko

There is a note that JQ 1.6 is required in the doc, but I will make it a bit bigger to make sure that people use it.
Thanks for feedback!


Add clipping method to MetaSWAP and MetaMod model

In GitLab by @JoerivanEngelen on May 15, 2023, 16:45
Add clipping method to MetaSWAP model object and MetaMod object.
MetaSWAP requires has no lateral flow, so no special boundary conditions are required at the clipped model's edges.

In GitLab by @JoerivanEngelen on Jun 26, 2023, 11:22
added #442 as child task

In GitLab by @JoerivanEngelen on Jun 26, 2023, 11:23
added #443 as child task

In GitLab by @JoerivanEngelen on Jun 26, 2023, 11:23
added #444 as child task


Alert: TargetDown in monitoring

Alert TargetDown firing in monitoring namespace
This is an automated issue created by the monitoring system. Please do not edit this message.
Alertmanager URL: https://alertmanager.ankhmorpork.thaum.xyz
Issue was last updated at 2023-02-28 00:34:19.218914484 +0000 UTC m=+940228.052736765.
Common Labels

alertname
TargetDown

cluster
ankhmorpork

job
probe/monitoring/uptimerobot

namespace
monitoring

prometheus
monitoring/k8s

severity
warning

Common Annotations

description
100% of the probe/monitoring/uptimerobot/ targets in monitoring namespace are down.

runbook_url
https://runbooks.prometheus-operator.dev/runbooks/general/targetdown

summary
One or more targets are unreachable.

Alerts

StartsAt
Links

2023-02-28 00:23:48.612 +0000 UTC
GeneratorURL

(DO NOT MODIFY: 969cd8f438af29792aef28905024b1fd202dbe3ce661ad0be1e26934755694d6 )

Fixed with https://github.com/thaum-xyz/ankhmorpork/commit/3d851f3e46285a1dbf4d9421e761ef77d3ac2fcb

Flaky service.


Make podSubnet consistent across install guide

In the Kind Getting Started page, we properly quote podSubnet as according to the kind config page. However, later in the guide, we don't quote podSubnet, leaving a user with inconsistent configurations. Making quotes standard.
Please ensure your pull request adheres to the following guidelines:
Signed-off-by: Jed Salazar<EMAIL_ADDRESS>

I should note that I looked across all the docs and this is the only spot I could locate the inconsistency.

Coverage decreased (-0.01%) to 37.164% when pulling bc69f997861f1c3330de1577ffc1d9702a782d71 on jedsalazar:pr/fix-quotes-in-podsubnet into 3f5c6c5600296b833bfc2dbc3117b81c1ae48e25 on cilium:master.

@jedsalazar can you sign off the commit and try to keep 80 columns of text in the git message? Thanks

Signed-off-by: Jed Salazar<EMAIL_ADDRESS>

@jedsalazar can you sign off the commit and try to keep 80 columns of text in the git message? Thanks

Thnaks, @aanm. How does that look?

@jedsalazar can you sign off the commit and try to keep 80 columns of text in the git message? Thanks

Thanks, @aanm. How does that look?

Just git commit --amend -s and force push it.


Namespace xmlns:xhtml="http://www.w3.org/1999/xhtml" missing in serialization

Prerequisites

[x ] I have written a descriptive issue title
[x ] I have verified that I am running the latest version of the ReqIFSharp
x[ ] I have searched open and closed issues to ensure it has not already been reported

Description

I used the code from ReqIFSerializerTestFixture and tested it to become familiar with functions and API.
I checked the resulting ReqIF against reqif.xsd and found the missing namespace for xhtml. After inserting the missing namespace it runs. I have no deep experiences in ReqIF or XML.
Steps to Reproduce

Run the example code in LinqPAD (NET Framework)
( from ReqIFSerializerTestFixture, serialization added)
Inspect result *.reqIf file

System Configuration

ReqIFSharp version:

[x ] ReqIFSharp:
[ ] Other:

Environment (Operating system, version and so on): Windows 10.
.NET Framework version: 4.6.2
Additional information:

I think I have to use the xhtml namespace inside the value. The test has another focus.

I misunderstood the purpose of the test I misused.

Thanks a lot. Your reference to your docs was helpful. Meanwhile, I've solved the issue and can read/write ReqIF with the help of ReqIFSharp.
If someone needs some code, a simple example of how to write ReqIF based on your test cases, contact me. I'm happy to share it.
Best regards,
Helmut