Use `pin_run_as_build` variants #56

jakirkham · 2018-04-28T22:59:50Z

Tries to use the variant pinning strategy described in the docs. Not sure if this is the best way to do this. Also unsure as to whether it can be simplified/relaxed further. Feedback welcome.

Checklist

Used a fork of the feedstock to propose changes
Bumped the build number (if the version is unchanged)
Reset the build number to 0 (if the version changed)
Re-rendered with the latest conda-smithy
Ensured the license file is being packaged.

Closes #62

ref: #54

cc @isuruf @msarahan

conda-forge-linter · 2018-04-28T22:59:55Z

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 · 2018-04-28T23:00:02Z

@conda-forge-admin, please re-render.

isuruf · 2018-04-28T23:02:45Z

recipe/meta.yaml

-    - libtiff 4.0.*
-    - jsoncpp  # [unix]
-    - expat
+    - zlib {{ zlib }}


You don't {{ zlib }} here

How do I know which cases to use {{ pkg }} versus not using them? If I drop the {{ pkg }} syntax, is it equivalent to having it because of the changes in PR ( conda-forge/conda-forge-pinning-feedstock#46 ). Sorry still trying to wrap my head around the features in conda-build 3 related to pinning.

If I drop the {{ pkg }} syntax, is it equivalent to having it because of the changes in PR ( conda-forge/conda-forge-pinning-feedstock#46 ).

Yes

jakirkham · 2018-04-28T23:03:45Z

@conda-forge-admin, please re-render.

jakirkham · 2018-04-29T00:31:27Z

Appears the pinnings may not be tight enough in some cases. Here's a loading error with freetype and libpng.

Traceback (most recent call last):
  File "/Users/distiller/miniconda3/conda-bld/vtk_1524956796987/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.5/site-packages/vtk/vtkRenderingFreeType.py", line 5, in <module>
    from .vtkRenderingFreeTypePython import *
ImportError: dlopen(/Users/distiller/miniconda3/conda-bld/vtk_1524956796987/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/python3.5/site-packages/vtk/vtkRenderingFreeTypePython.so, 2): Library not loaded: @rpath/libpng16.16.dylib
  Referenced from: /Users/distiller/miniconda3/conda-bld/vtk_1524956796987/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/libfreetype.6.dylib
  Reason: Incompatible library version: libfreetype.6.dylib requires version 51.0.0 or later, but libpng16.16.dylib provides version 49.0.0

Edit: ...or at least some rebuilding needs to occur with the newer versions in our pinning file.

isuruf · 2018-04-29T00:35:36Z

It's because libpng pinning was wrong in freetype. This is fixed with conda-forge/conda-forge-pinning-feedstock#52

looooo · 2018-05-09T11:18:12Z

@isuruf @jakirkham if this is fixed now, can you rerender?

jakirkham · 2018-05-09T13:09:39Z

It’s not yet fixed. We are discussing in PR ( conda-forge/conda-forge-pinning-feedstock#52 ).

jakirkham · 2018-05-13T08:29:39Z

@conda-forge-admin, please re-render.

jakirkham · 2018-05-24T14:01:55Z

Will give this another go this evening given new pinnings are out.

Instead of relying on the `toolchain` (directly) or `vc` features (directly), use the `compiler` in the `build` section to enforce compiler and runtime match up. Also split out the `host` dependencies from the `build` dependencies.

These are already pinned automatically by `conda-build` due to the variant files provided with their pinnings. So we don't need to manually set the pinning requirements ourselves. Hence they are dropped for simplicity.

Re-render now that the new compiler syntax is in use. Pinnings are now set based on `conda-forge-pinning`.

Needed for updated pinnings.

As much of the stack is still using `hdf5` version `1.10.1`, pin `vtk` to that specific version of `hdf5` even though the pinnings now use `hdf5` version `1.10.2`. Ultimately this should be reverted once the rest of stack (specifically `libnetcdf` is rebuilt with `hdf5` version `1.10.2`). This should provide us a way forward rebuilding `vtk` with newer pinnings in the interim.

As `hdf5` has been pinned manually to `1.10.1` (temporarily), re-render to remove this pinning from the variant file.

jakirkham · 2018-05-25T03:02:04Z

recipe/meta.yaml

-    - zlib 1.2.11
-    - freetype 2.8.1
+    - zlib
+    - freetype
    - hdf5 1.10.1


Currently libnetcdf is using hdf5 version 1.10.1. So we are unable to use 1.10.2 here yet. Have manually pinned this until libnetcdf is rebuilt.

xref: conda-forge/libnetcdf-feedstock#45

so whats the reason for pinning 1.10.2 in conda-forge-pinnings if it introduce that much trouble?

We want to update. We just haven't rebuilt everything yet.

Ultimately this could be said of any time we update pinnings actually. Nothing will be using them yet and if a lot of packages are dependent on it, there will be work to upgrade them. That work is significantly less given our new tooling, but it still needs to be done.

jakirkham · 2018-05-25T03:15:18Z

Ran into issue ( conda-forge/conda-smithy#775 ). Submitted PR ( conda-forge/conda-smithy#785 ) to fix it. This seems to work based on local testing.

Edit: Fix included in conda-smithy version 3.1.5.

In order to fix an issue with `yum_requirements.txt` not being used in the re-rendering on Linux, update to the latest `conda-smithy` release and re-render. Should fix a recent failure seen on CIs due to the absence of these requirements from `yum`.

jakirkham · 2018-05-25T04:23:02Z

So this looks ok thus far, but it will take a while to build. We can let it build through. Though given the length of the build, we might need to do the merge Friday evening (assuming all goes well 🍀) to avoid swamping CIs during the day.

jakirkham · 2018-05-26T06:36:40Z

All packages are now deployed. 🎉 Enjoy. 😄

isuruf reviewed Apr 28, 2018

View reviewed changes

jakirkham force-pushed the use_pin_run_as_build branch from d63e7ff to 675105c Compare April 28, 2018 23:03

looooo mentioned this pull request May 9, 2018

Re-Enable MacOs Build #47

Closed

jakirkham mentioned this pull request May 12, 2018

Refresh manual pins #59

Merged

5 tasks

jakirkham force-pushed the use_pin_run_as_build branch from f87f5cb to 158e968 Compare May 13, 2018 08:29

jakirkham mentioned this pull request May 24, 2018

align to conda-forge pinnings #62

Closed

jakirkham added 4 commits May 24, 2018 22:37

Use the new compiler syntax

a17cea6

Instead of relying on the `toolchain` (directly) or `vc` features (directly), use the `compiler` in the `build` section to enforce compiler and runtime match up. Also split out the `host` dependencies from the `build` dependencies.

Leverage pin_run_as_build to set runtime reqs

43adf22

These are already pinned automatically by `conda-build` due to the variant files provided with their pinnings. So we don't need to manually set the pinning requirements ourselves. Hence they are dropped for simplicity.

MNT: Re-rendered with conda-smithy 3.1.4 and pinning 2018.05.22

a8269f8

Re-render now that the new compiler syntax is in use. Pinnings are now set based on `conda-forge-pinning`.

Bump build number to 1

34b9119

Needed for updated pinnings.

jakirkham force-pushed the use_pin_run_as_build branch from ff46191 to 34b9119 Compare May 25, 2018 02:40

jakirkham added 2 commits May 24, 2018 22:45

MNT: Re-rendered with conda-smithy 3.1.4 and pinning 2018.05.22

c02b599

As `hdf5` has been pinned manually to `1.10.1` (temporarily), re-render to remove this pinning from the variant file.

jakirkham commented May 25, 2018

View reviewed changes

jakirkham changed the title ~~WIP: Use pin_run_as_build variants~~ Use pin_run_as_build variants May 25, 2018

jakirkham merged commit 3df9781 into conda-forge:master May 26, 2018

jakirkham deleted the use_pin_run_as_build branch May 26, 2018 03:40

aslakbergersen mentioned this pull request Jan 18, 2019

Move to Conda-Forge? vmtk/conda-recipes#2

Open

Uh oh!

Use pin_run_as_build variants #56

Use pin_run_as_build variants #56

Uh oh!

Conversation

jakirkham commented Apr 28, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

conda-forge-linter commented Apr 28, 2018

Uh oh!

jakirkham commented Apr 28, 2018

Uh oh!

isuruf Apr 28, 2018

Choose a reason for hiding this comment

Uh oh!

jakirkham Apr 28, 2018

Choose a reason for hiding this comment

Uh oh!

isuruf Apr 28, 2018

Choose a reason for hiding this comment

Uh oh!

jakirkham commented Apr 28, 2018

Uh oh!

jakirkham commented Apr 29, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

isuruf commented Apr 29, 2018

Uh oh!

looooo commented May 9, 2018

Uh oh!

jakirkham commented May 9, 2018

Uh oh!

jakirkham commented May 13, 2018

Uh oh!

jakirkham commented May 24, 2018

Uh oh!

jakirkham May 25, 2018

Choose a reason for hiding this comment

Uh oh!

looooo May 25, 2018

Choose a reason for hiding this comment

Uh oh!

jakirkham May 25, 2018

Choose a reason for hiding this comment

Uh oh!

jakirkham May 25, 2018

Choose a reason for hiding this comment

Uh oh!

jakirkham commented May 25, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jakirkham commented May 25, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jakirkham commented May 26, 2018

Uh oh!

Uh oh!

Use `pin_run_as_build` variants #56

Use `pin_run_as_build` variants #56

jakirkham commented Apr 28, 2018 •

edited

Loading

jakirkham commented Apr 29, 2018 •

edited

Loading

jakirkham commented May 25, 2018 •

edited

Loading

jakirkham commented May 25, 2018 •

edited

Loading