What changes were proposed in this pull request?

This PR aims to replace mvn with mvnw in java.CMakeLists.txt.

Why are the changes needed?

Some old OSes like CentOS7 may have the old Maven installation. Maven Wrapper will prevent build and test failures.

How was this patch tested?

Pass the CIs.

This is the specific reason why I have introduced PEP-517 build and I was hoping that having production grade build openly documented in our GitHub actions would further aid users of this group.

Can you link me to the docs on this? I wasn't aware of an alternative build of snowflake-connector-python that has looser constraints on dependencies.

I don't see an alternative wheel / sdist tarball at https://pypi.org/project/snowflake-connector-python/#files or on the latest release. That isn't mentioned in https://docs.snowflake.com/en/user-guide/python-connector-install.html or https://docs.snowflake.com/en/user-guide/python-connector-dependencies.html.

please add the next major pin

Sure, thanks for hearing me out. Added in https://github.com/snowflakedb/snowflake-connector-python/pull/604/commits/e8ff9a2d2dcec0f1dd75de2814b9665ab809808a

Sounds good!

#9291 is good progress towards eliminating use of the function.

And certainly, we could 'split' the macro for primitives as a quick fix to get rid of the call to the function. I've been experimenting with an alternative approach that might be a bit more flexible to multiple use cases, described at the bottom of this comment.

I am quite torn about whether I think value should or should not be in the interface.

Reasons to drop value(i) -> T::Native

I think that even if value(i) was dropped from the PrimitiveArray impl's, efficient random access to items without a bounds check can still be achieved through unsafe{*primitive_array.values().get_unchecked(i)} (the extra * because get_unchecked() returns a ref to the value).

I'm not sure I have any example code or measurements to demonstrate it on hand, but I am certain I saw the silently-unsafe implementationx.values().iter().zip(y.values().iter()) did (slightly) outperform (0..x.len()).map(|i|{x.value(i),y.value(i)}. I believe it was when I was playing with non-simd arithmetic kernels.... So that is the root of my hesitancy, is I'm worried it doesn't actually escape any overhead, and unintentionally lead people away from a more reliable/performant way. IF there is a context where unsafe{x.value(i)} beats the performance of unsafe{*x.values().get_unchecked(i)}

Reasons to keep value(i) -> T::Native

All other array implementations have value functions as far as I recall, so it is a nice 'consistency'.

In the back of my mind, the biggest argument to keep value(i) is for api consistency... so long term, a 'trait' may be the place where it might fit best? Very roughly, I'm thinking:

trait TypedArrowArray : ArrowArray {
   type RefType;
   fn is_valid(i:usize) -> bool; //bounds check
   unsafe fn is_valid(i:usize) -> bool; //no bounds check
   fn value(i:usize) -> RefType;  //bounds check
   unsafe fn value_unchecked(i:usize) -> RefType; //no bounds checked
   fn iter() -> impl Iterator<Option<RefType>>;
   fn iter_values() -> impl Iterator<RefType>;
}
impl <T: ArrowPrimitiveType> TypedArrowArray<&T::Native> for PrimitiveArray<T> { ... }
impl TypedArrowArray<ArrayRef> for GenericListArray<T> { ... }
//and similar for string/binary. ... I am not sure whether struct arrays could fit... Dictionary would not give access to 'keys', only to the values referenced by each key?  Union would require some kind of RefType that can downcast into the actual value?

Of course, I am uncertain how much overhead the 'standarization' such a trait impl implies would bring... would any kernels actually benefit from using generic implementations against such an api, or will they always go down to the concrete type to squeeze little short-cuts out that don't fit in the generic interface? I'm unsure, so very (very, very) slowly experimenting...

Summary

So in short, my thoughts are:

• I think that leaving value(i) safety consideration out of this PR makes sense. I've rebased to drop that out - although I did leave the additional values() test code.
• Marking it unsafe in the near future is absolutely better than being silently-unsafe. The argument that adding bounds-checks could silently impact external users is reasonable, taking unsafe has the larger 'warning' so that the change isn't missed.
• Longer term, the options of deprecating it, or explicitly moving it into an trait impl are both contenders in my mind... but neither option is directly relevant to this PR.

Let me know if that seems reasonable.

The rebase didn't apply cleanly to 1.3.1073, had to rebase some patches manually. I suggest reviewing https://github.com/conda-forge/staged-recipes/pull/13760/commits/9c2d23d93c0296f5ab8098c4696ddf847a67e8a6 with whitespace changes ignored. Very likely a line-ending thing, which I can fix if absolutely necessary (but these are just the output of git format-patch tags/v1.3.1073; on windows, no less...)

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 (recipes/cppbktree) and found it was in an excellent condition.

<!-- Thank you very much for putting in this recipe PR!

This repository is very active, so if you need help with a PR or once it's ready for review, please let the right people know. There are language-specific teams for reviewing recipes.

Currently available teams are:

• python @conda-forge/help-python
• python/c hybrid @conda-forge/help-python-c
• r @conda-forge/help-r
• java @conda-forge/help-java
• nodejs @conda-forge/help-nodejs
• c/c++ @conda-forge/help-c-cpp
• perl @conda-forge/help-perl
• Julia @conda-forge/help-julia
• ruby @conda-forge/help-ruby

If your PR doesn't fall into those categories please contact the full review team @conda-forge/staged-recipes.

Due to GitHub limitations first time contributors to conda-forge are unable to ping these teams. You can ping the team using a special command in a comment on the PR to get the attention of the staged-recipes team. You can also consider asking on our Gitter channel or on our Keybase chat if your recipe isn't reviewed promptly. -->

Checklist

• [ ] Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml"
• [ ] License file is packaged (see here for an example)
• [ ] Source is from official source
• [ ] Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged)
• [ ] If static libraries are linked in, the license of the static library is packaged.
• [ ] Build number is 0
• [ ] A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details)
• [ ] GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there
• [ ] When in trouble, please check our knowledge base documentation before pinging a team.

There was nothing about SOCI_LIBRARIES in 1.3.1073, particularly not in src/cpp/CMakeLists.txt. Skipped this patch.

@conda-forge/help-python Can someone help with the Linux build error? Python 3.9 comes with tkinter, but it throws an ImportError: libX11.so.6: cannot open shared object file: No such file or directory. Thanks.

import: 'whiteboxgui'
Traceback (most recent call last):
  File "/home/conda/staged-recipes/build_artifacts/whiteboxgui_1611356481727/test_tmp/run_test.py", line 2, in <module>
    import whiteboxgui
  File "/home/conda/staged-recipes/build_artifacts/whiteboxgui_1611356481727/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/python3.9/site-packages/whiteboxgui/__init__.py", line 7, in <module>
    from .whiteboxgui import show
  File "/home/conda/staged-recipes/build_artifacts/whiteboxgui_1611356481727/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/python3.9/site-packages/whiteboxgui/whiteboxgui.py", line 8, in <module>
    import whitebox
  File "/home/conda/staged-recipes/build_artifacts/whiteboxgui_1611356481727/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/python3.9/site-packages/whitebox/__init__.py", line 10, in <module>
    from .wb_runner import Runner
  File "/home/conda/staged-recipes/build_artifacts/whiteboxgui_1611356481727/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/python3.9/site-packages/whitebox/wb_runner.py", line 24, in <module>
    import tkinter as tk
  File "/home/conda/staged-recipes/build_artifacts/whiteboxgui_1611356481727/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/python3.9/tkinter/__init__.py", line 37, in <module>
    import _tkinter # If this fails your Python may not be configured for Tk
ImportError: libX11.so.6: cannot open shared object file: No such file or directory
Tests failed for whiteboxgui-0.1.2-pyh44b312d_0.tar.bz2 - moving package to /home/conda/staged-recipes/build_artifacts/broken
WARNING conda_build.build:tests_failed(2955): Tests failed for whiteboxgui-0.1.2-pyh44b312d_0.tar.bz2 - moving package to /home/conda/staged-recipes/build_artifacts/broken
TESTS FAILED: whiteboxgui-0.1.2-pyh44b312d_0.tar.bz2

Thank you @ocefpaf!

SNOW-266042 Description Added logging for Query ID before ping-pong of query result retrieval. This made debugging easier for the case when query result retrieval fails after a query succeeded. Added logging for Request ID and Request GUID.

So I'm thinking that rather than rewrite the metrics during schema transformation, when the schema is loaded we convert the from column names to references. What do folks think?

Following up on https://github.com/dask/dask/pull/7069, now that https://github.com/conda-forge/cytoolz-feedstock/issues/36 has been resolved we can add cytoolz back to the CI environment.

• [ ] Tests added / passed
• [ ] Passes black dask / flake8 dask

Can we add a small test for this? Have you manually tested this?

This has been manually tested.

Sorry for the mistake.

The win build failed, since the upstream doesn't support Windows (it calls external dependencies.) But this is noarch. Is it necessary to add skip: true # [win] in this case?

Thanks.

I agree with you James and this is something that many customers have been asking for (there are many other issues open with this request already).

Short answer of why this is that historically our library has been treated as an application, so now many of our customers demand that we minimize the possibility of errors, but this is only possible if we control dependency versions.

I wasn't here when this decision was made, so I can't comment on the specifics of why, but if I had to take a guess our library broke way too often. I have definitely seen this myself many times. For example this new pyjwt release had the possibility of breaking customer deployments as you found. Not once did we have to get online over the weekends to pin against certain newly released dependencies and do an unscheduled release of the connector to fix things. Over the years this lead to the state we are in now. I'm trying to make a better effort to keep things up to date, but I'd lying if I said that I'm on top of everything, this is why we introduced dependabot. It kicks off tests every dependency bump before actually moving our pin.

My other view is that if there are people that would like our library with less tightly coupled dependencies, they can really easily build it for themselves. This is the specific reason why I have introduced PEP-517 build and I was hoping that having production grade build openly documented in our GitHub actions would further aid users of this group.

I hope that this insight makes sense to you and that you find it to make at least some sense, that being said please add the next major pin, we should test at least breaking public API changes.

Following up on https://github.com/dask/dask/pull/7069, now that https://github.com/conda-forge/cytoolz-feedstock/issues/36 has been resolved we can add cytoolz back to the CI environment.

• [ ] Tests added / passed
• [ ] Passes black dask / flake8 dask

@kszucs that didn't trigger a Travis build for some reason

FYI, the version of vcpkg that is currently preinstalled on the Github Actions Windows images is 2020.11.12 (as noted here). This version has a bug (https://github.com/awslabs/aws-c-common/issues/734) that causes the installation of aws-cpp-sdk to fail. When running vcpkg in Github Actions on Windows, remove the preinstalled vcpkg and install the newest version from source.

Yes. Tested with 21.01.0 and the aforementioned PDF and got an empty tiff.

@dopplershift, sorry to bother you, I think this is the same case as in https://github.com/conda-forge/staged-recipes/pull/13527#pullrequestreview-574572704 , could you help merging this? Thanks.

This line shouldn't change without adding urllib3 as a direct dependency of ours.