search

conda-forge / omniscidb-cpu-feedstock

A conda-smithy repository for omniscidb-cpu.
BSD 3-Clause "New" or "Revised" License
1 stars 5 forks source link

Use arrow-cpp's run_export #16

Closed jakirkham closed 5 years ago

jakirkham commented 5 years ago

Makes sure we use arrow-cpp's run_export to determine the version of arrow-cpp we use at runtime.

Checklist

Fixes https://github.com/conda-forge/omniscidb-cpu-feedstock/issues/15

xref: https://github.com/conda-forge/conda-forge-pinning-feedstock/issues/321#issuecomment-550536461

conda-forge-linter commented 5 years ago

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.

jakirkham commented 5 years ago

There is also arrow-cpp >=0.13.0 in host that we probably should drop. Thoughts?

xhochy commented 5 years ago

We should remove the version from host and let conda-forge-pinning handle it.

xmnlab commented 5 years ago

LGTM. @pearu do you have any thoughts about this PR?

jakirkham commented 5 years ago

We should remove the version from host and let conda-forge-pinning handle it.

Sounds good. Done 😄

xhochy commented 5 years ago

@conda-forge-admin please rerender

@jakirkham arrow-cpp should appear in the pinnings file.

conda-forge-linter commented 5 years ago

Hi! This is the friendly automated conda-forge-webservice.

I tried to re-render for you, but it looks like I wasn't able to push to the use_arrow-cpp_run_export branch of jakirkham-feedstocks/omniscidb-cpu-feedstock. Did you check the "Allow edits from maintainers" box?

pearu commented 5 years ago

Is there a way to restart the failing osx check?

jakirkham commented 5 years ago

Yeah I've done that manually.

jakirkham commented 5 years ago

@jakirkham arrow-cpp should appear in the pinnings file.

We could add it back to run. Though that might cause issues since we are pinnined to 0.15.0 globally and that version didn't have the run_export. How do you think we should handle this? My hope is to get through these PRs and then bump to 0.15.1. Though would be open to other ideas 🙂

xhochy commented 5 years ago

@jakirkham I would suspect that a rerender adds arrow-cpp to the pinnings file. Thus I called @conda-forge-admin please rerender

xhochy commented 5 years ago

Otherwise feel free to merge an start the new pinning migration.

conda-forge-linter commented 5 years ago

Hi! This is the friendly automated conda-forge-webservice.

I tried to re-render for you, but it looks like I wasn't able to push to the use_arrow-cpp_run_export branch of jakirkham-feedstocks/omniscidb-cpu-feedstock. Did you check the "Allow edits from maintainers" box?

conda-forge-linter commented 5 years ago

Hi! This is the friendly automated conda-forge-webservice.

I tried to re-render for you, but it looks like I wasn't able to push to the use_arrow-cpp_run_export branch of jakirkham-feedstocks/omniscidb-cpu-feedstock. Did you check the "Allow edits from maintainers" box?

jakirkham commented 5 years ago

I’ll give it a go local.

jakirkham commented 5 years ago

@xhochy, have pushed this in the latest commit 🙂

jakirkham commented 5 years ago

It looks like this pinning is resulting in an unresolvable state. How do you feel about overriding the pinning here to use arrow-cpp version 0.15.1?

Package zstd conflicts for:
libarchive=3.3 -> zstd[version='>=1.3.3,<1.3.4.0a0|>=1.3.7,<1.3.8.0a0|>=1.4.0,<1.4.1.0a0']
arrow-cpp=0.15.0 -> zstd[version='>=1.4.0,<1.4.1.0a0|>=1.4.3,<1.4.4.0a0']
libgdal[version='>=2.3.*,<3'] -> libtiff[version='>=4.0.10,<5.0a0'] -> zstd[version='>=1.3.3,<1.3.4.0a0|>=1.3.7,<1.3.8.0a0|>=1.4.0,<1.4.1.0a0|>=1.4.3,<1.4.4.0a0']
blosc -> zstd[version='>=1.3.7,<1.3.8.0a0']

ref: https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=91414&view=logs&jobId=1bf226d3-0e2f-52d8-fa93-7d9e633347b3

xhochy commented 5 years ago

blosc -> zstd[version='>=1.3.7,<1.3.8.0a0'] is a confusing line as blosc has no dependencies: https://github.com/conda-forge/blosc-feedstock/blob/eb457e12ea87803f4d70dc29975d9c428ff174c9/recipe/meta.yaml#L22

The actual problem here is that all newer arrow-cpp versions are built against boost-cpp=1.70. So we cannot upgrade arrow-cpp here unless we either update boost-cpp here or build arrow-cpp against multiple boost versions.

pearu commented 5 years ago

Unfortunately, omniscidb 4.8 build will fail with newer boost-cpp versions.

pearu commented 5 years ago

However, the next release (not available yet) seems to support newer boost versions (not tested).

jakirkham commented 5 years ago

In that case, I'm going to close this out. There doesn't seem to be a clear path forward without a new release. Hopefully you, @pearu, will be able to tackle this in the next release?

pearu commented 5 years ago

I can now confirm that the unreleased omniscidb builds ok with boost-cpp 1.70. @jakirkham , sure, I'll tackle this. IIUC, the aim is to specify arrow-cpp and boost-cpp without version restrictions (I haven't look into what run_export does, yet)

jakirkham commented 5 years ago

Basically run_export says if you link against a dependency in host, it will be automatically added to run with a version constraint determined by that package.