Skip to content

Rebuild for orc166#234

Merged
github-actions[bot] merged 5 commits intoconda-forge:masterfrom
regro-cf-autotick-bot:rebuild-orc166-0-1_h667a6b
Dec 22, 2020
Merged

Rebuild for orc166#234
github-actions[bot] merged 5 commits intoconda-forge:masterfrom
regro-cf-autotick-bot:rebuild-orc166-0-1_h667a6b

Conversation

@regro-cf-autotick-bot
Copy link
Copy Markdown
Contributor

This PR has been triggered in an effort to update orc166.

Notes and instructions for merging this PR:

  1. Please merge the PR only after the tests have passed.
  2. Feel free to push to the bot's branch to update this PR if needed.

Please note that if you close this PR we presume that the feedstock has been rebuilt, so if you are going to perform the rebuild yourself don't close this PR until the your rebuild has been merged.

This package has the following downstream children:

And potentially more.

If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase @conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

This PR was created by the regro-cf-autotick-bot.
The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. If you would like a local version of this bot, you might consider using rever. Rever is a tool for automating software releases and forms the backbone of the bot's conda-forge PRing capability. Rever is both conda (conda install -c conda-forge rever) and pip (pip install re-ver) installable.
Finally, feel free to drop us a line if there are any issues!
This PR was generated by https://github.com/regro/autotick-bot/actions/runs/436652371, please use this URL for debugging

@conda-forge-linter
Copy link
Copy Markdown
Contributor

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.

@xhochy
Copy link
Copy Markdown
Member

xhochy commented Dec 22, 2020

@conda-forge-admin please rerender

@github-actions
Copy link
Copy Markdown
Contributor

Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you, but it looks like there was nothing to do.

@xhochy
Copy link
Copy Markdown
Member

xhochy commented Dec 22, 2020

@conda-forge-admin please rerender

@xhochy xhochy added the automerge Merge the PR when CI passes label Dec 22, 2020
Comment on lines 49 to 50
ignore_run_exports:
- cudatoolkit
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
ignore_run_exports:
- cudatoolkit
ignore_run_exports_from:
- {{ compiler('cuda') }}
- boost-cpp >=1.70

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

boost-cpp doesn't have a run_exports so this section should not be needed at all.

@mbargull mbargull removed the automerge Merge the PR when CI passes label Dec 22, 2020
@mbargull
Copy link
Copy Markdown
Member

I've removed automerge due to review.

@mbargull
Copy link
Copy Markdown
Member

Question about arrow-cpp and its libarrow_python/libarrow_python_flight: What is their relationship to the actual python package? They don't appear to (dynamically) link to libpython and arrow-cpp itself does not include any Python package. Are they dependent on the Python version, i.e., do we need separate builds for each python?

@xhochy
Copy link
Copy Markdown
Member

xhochy commented Dec 22, 2020

Question about arrow-cpp and its libarrow_python/libarrow_python_flight: What is their relationship to the actual python package? They don't appear to (dynamically) link to libpython and arrow-cpp itself does not include any Python package. Are they dependent on the Python version, i.e., do we need separate builds for each python?

Yes, they are dependent on the Python version and use symbols from Python. They don't link against libpython as they don't embed an interpreter and thus as-recommened should inherit the symbols from the Python executable that loads them.

@xhochy
Copy link
Copy Markdown
Member

xhochy commented Dec 22, 2020

Question about arrow-cpp and its libarrow_python/libarrow_python_flight: What is their relationship to the actual python package? They don't appear to (dynamically) link to libpython and arrow-cpp itself does not include any Python package. Are they dependent on the Python version, i.e., do we need separate builds for each python?

Oh and the libarrow_python is the part that actually contains the complicated Python logic where the pyarrow package itself is mostly Cython-based glue code to it.

@mbargull
Copy link
Copy Markdown
Member

Question about arrow-cpp and its libarrow_python/libarrow_python_flight: What is their relationship to the actual python package? They don't appear to (dynamically) link to libpython and arrow-cpp itself does not include any Python package. Are they dependent on the Python version, i.e., do we need separate builds for each python?

Yes, they are dependent on the Python version and use symbols from Python. They don't link against libpython as they don't embed an interpreter and thus as-recommened should inherit the symbols from the Python executable that loads them.

Thanks! Would it make sense to split them up into a subpackage to reduce redundancy (on CI and package repository) with the reset of the package?

@mbargull
Copy link
Copy Markdown
Member

Oh and the libarrow_python is the part that actually contains the complicated Python logic where the pyarrow package itself is mostly Cython-based glue code to it.

Ah, makes sense. But they are expected to live in arrow-cpp or could(/should?) we move them to pyarrow?

@xhochy
Copy link
Copy Markdown
Member

xhochy commented Dec 22, 2020

It's expected to be in arrow-cpp as it is currently, sadly that introduces a Python dependency on r-arrow.

I hope to have time somewhere in Spring 2020 to split this recipe into ~10 outputs (libarrow, libarrow_python, libarrow_flight, libgandiva, pyarrow, pyarrow.gandiva, ...) but that needs changes in upstream first. This will not reduce the build matrix though but at least keep it at the same size as currently.

@xhochy
Copy link
Copy Markdown
Member

xhochy commented Dec 22, 2020

As arrow-cpp is the feedstock that is my main (initial) conda-forge motivation, I also blog about the progress since some weeks:

@mbargull
Copy link
Copy Markdown
Member

Perfect, thanks for all the explanations! :)

@mbargull mbargull added the automerge Merge the PR when CI passes label Dec 22, 2020
@github-actions github-actions bot merged commit 2011622 into conda-forge:master Dec 22, 2020
@github-actions
Copy link
Copy Markdown
Contributor

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

  • linter: passed
  • drone: passed
  • azure: passed

Thus the PR was passing and merged! Have a great day!

@regro-cf-autotick-bot regro-cf-autotick-bot deleted the rebuild-orc166-0-1_h667a6b branch December 22, 2020 08:55
@h-vetinari h-vetinari mentioned this pull request Sep 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

automerge Merge the PR when CI passes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants