conda-forge / conda-forge-pinning-feedstock Goto Github PK

Currently we require flang on Windows. This works ok for VC14, but not for VC9. Would be nice to have some alternate strategy for VC9 (including simply not using flang there).

ref: conda-forge/fftw-feedstock#43 (review)

How should we handle the compilers for R/MinGW ?

- {{ compiler('c') }}   # [unix]
- mingw-toolchain       # [win]

- {{ compiler('c') }}         # [unix]
- {{ compiler('mingw_c') }}   # [win]

- {{ compiler('r_base_c') }}

- {{ compiler('c') }}         # [unix]
- {{ compiler('m2w64_c') }}   # [win]

cc @conda-forge/core, @mingwandroid, @conda-forge/r-base

Raising this to see if suitesparse should be pinned globally.

re conda-forge/cvxopt-feedstock#19

curl 7.44 should be changed to 7 and max_pin: x

Defaults has updated to glib 2.56, while we're still pinning to 2.55. Does this mean that we should consider updating our pin?

Motivated by pygobject-feedstock #9.

(moved from conda-forge/staged-recipes#5355)

This might be a beginner's question, but I couldn't find any documentation on this problem, although I saw issues open about this (like conda-forge/staged-recipes#475).

When I build a C++ package, it links to whatever version of a library gets pulled by conda build. So let's say it links my products to libCLHEP.so.2.2.0.8.

If a user downloads the package and gets a newer version (say libCLHEP.so.2.2.0.9), then the link breaks.

Of course, I can fix this by pinning to a specific library version in my meta.yaml file, but this is overly restrictive. In fact, my software can work with say any CLHEP >= 2.2. But adding that to meta.yaml will not work because the links happens with the versioned library at build time.

I looked for some kind of flags for the linker so that it links against libCLHEP.so instead of libCLHEP.so.2.2.0.8 but couldn't find one...

how can I solve this problem?

Issue:

In the bioconda testing environment, that uses the conda-forge build configuration, when using {{ compiler('cxx') }}, I get the cmake error:

Compiler Detection
CMake Error at /opt/conda/conda-bld/lambda_1545054353812/_build_env/share/cmake-3.13/Modules/CMakeDetermineCXXCompiler.cmake:47 (message):
  Could not find compiler set in environment variable CXX:

  g++.

Call Stack (most recent call first):
  CMakeLists.txt:13 (project)


CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!

However, once I replace it with the following build requirements, cmake finds the compiler and everything works smoothly:

    - gxx_linux-64 # [linux]
    - clangxx_osx-64 # [osx]

From the cxx_compiler build config of conda-forge, I would have assumed that {{ compiler('cxx') }} would pull in exactly these dependencies, but the packages that look cxx-related that get installed in the build environment are (full list below):

    libgcc-ng:              7.2.0-hdf63c60_3        conda-forge
    libstdcxx-ng:           7.2.0-hdf63c60_3        conda-forge
    llvm-meta:              7.0.0-0                 conda-forge
    toolchain:              2.3.0-0                 conda-forge
    toolchain_cxx_linux-64: 2.3.0-0                 conda-forge

Any ideas, why the relevant packages are not pulled in? Anything obvious, that I am missing?

$ conda list
    bzip2:                  1.0.6-h470a237_2        conda-forge
    ca-certificates:        2018.11.29-ha4d7672_0   conda-forge
    cmake:                  3.13.1-h011004d_0       conda-forge
    curl:                   7.63.0-h74213dd_0       conda-forge
    expat:                  2.2.5-hfc679d8_2        conda-forge
    krb5:                   1.16.2-hbb41f41_0       conda-forge
    libcurl:                7.63.0-hbdb9355_0       conda-forge
    libedit:                3.1.20170329-haf1bffa_1 conda-forge
    libgcc-ng:              7.2.0-hdf63c60_3        conda-forge
    libssh2:                1.8.0-h5b517e9_3        conda-forge
    libstdcxx-ng:           7.2.0-hdf63c60_3        conda-forge
    libuv:                  1.24.0-h470a237_0       conda-forge
    llvm-meta:              7.0.0-0                 conda-forge
    ncurses:                6.1-hfc679d8_2          conda-forge
    openmp:                 7.0.0-h2d50403_0        conda-forge
    openssl:                1.0.2p-h470a237_1       conda-forge
    rhash:                  1.3.6-h470a237_1        conda-forge
    seqan-library:          2.4.0-0                 conda-forge
    tk:                     8.6.9-ha92aebf_0        conda-forge
    toolchain:              2.3.0-0                 conda-forge
    toolchain_cxx_linux-64: 2.3.0-0                 conda-forge
    xz:                     5.2.4-h470a237_1        conda-forge
    zlib:                   1.2.11-h470a237_3       conda-forge

This is a reminder to migrate the latest content from the pinning script to here.

cc @conda-forge/core

Would be great to include some sort of pinning for Leptonica. Requesting info for the tracker in issue ( lvc/upstream-tracker#59 ).

cc @conda-forge/leptonica

The ABI/API report for postgresql shows it is very stable, but does occasionally add symbols. Thoughts on how we would like to pin it?

Raising this to see how we would like to pin nspr. Here's the ABI/API Report, which looks pretty stable. The one removed symbol was from 4.17 to 4.18, which appears to be noted in the symbol name as being transient. We also skipped it. So maybe no pinning outside major version is needed? Not sure if there is anything else we should be doing here.

cc @conda-forge/nspr

Dropping win-32 from conda_build_config.yaml will drop win-32 support from all future feedstocks.

cc @conda-forge/core

Would it be possible to add tags for the releases on this repo?
I like checking changes between releases via https://github.com/conda-forge/conda-forge-pinning-feedstock/compare/ but it's a bit tedious to have to always browse through the history/blame to check which commits correspond to which releases..

We need some kind of test, maybe a dummy re-render, to ensure that we got the zip keys matrix correctly. It is very easy to update something and forget the update the matrix.

ping @mariusvniekerk

We put in a PR to pin gfortran at 4.* here.

However, this appears to not be working. See this build https://travis-ci.org/conda-forge/yaehmop-feedstock/builds/492415546

@conda-forge/core for viz

Any issues with this? cc @conda-forge/gsl @saraedum

@dougalsutherland commented on Thu Nov 02 2017

libedit should be pinned to something. But I'm not totally sure what: it seems that our libedit package is editline from http://thrysoee.dk/editline/, currently at version 3.1; the tracker entry for editline is for https://github.com/troglobit/editline/ (source), currently at version 1.15.2. I don't know what the relationship is between those two projects with the same name.

cc @conda-forge/libedit

@jakirkham commented on Thu Nov 02 2017

Do you mind following up with the LVC team? Here is their package issue tracker.

@dougalsutherland commented on Thu Nov 02 2017

Yep, it seems that the packages are actually just independent despite having the same name. lvc/upstream-tracker#21

@dougalsutherland commented on Fri Nov 03 2017

Looks like it's slightly complicated: https://abi-laboratory.pro/tracker/timeline/libedit/

That is, there are multiple 3.1 versions, tagged with dates. I guess maybe we should change the libedit recipe to add the date as a minor version?

@jakirkham commented on Fri Nov 03 2017

Agreed. Looks like the date is part of the libedit version for better or worse.

cc @conda-forge/libedit @mingwandroid

@dougalsutherland commented on Sun Nov 05 2017

I just merged a new mysql recipe with a build dependency of libedit 3.1.20170329 and run of libedit >=3.1.20170329, since it seems to be persistently backwards compatible even from 3.0 to 3.1. I know pin_the_slow_way doesn't support that yet, but... 🤷‍♀️.

@jakirkham commented on Mon Nov 13 2017

Maybe just encourage exact pinning for now? I don't think we are planning to do much with libedit yet.

@mingwandroid commented on Mon Nov 13 2017

Maybe just encourage exact pinning for now.

Why? https://abi-laboratory.pro/tracker/timeline/libedit

I am planning to do a lot with libedit and so would appreciate standardisation and as loose a pinning as strictly necessary here (and since its inception or at least as far back as abi-laboratory has tracked it, libedit has retained a 100% backwards compat. record).

Looks like libarchive is not pinned currently. Would be good if we could do so.

ref: https://abi-laboratory.pro/?view=timeline&l=libarchive

The ABI/API report for libsigcpp shows it removing symbols on patch releases. So not only should it be pinned, but it should be pinned tightly to avoid breakage.

@conda-forge/core, we need to come up with a decision about using pin_run_as_build and/or run_exports for new packages. (#89 (comment))

I thought the plan was to eventually migrate essentially everything that's currently in pin_run_as_build here to run_exports in the packages, and (except maybe in some unusual situations) eventually remove all of the pin_run_as_build entries. Apparently not everyone agrees that's the plan: conda-forge/staged-recipes#4858 (comment)

I know @msarahan started a poll about this a while ago. What came of that?

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

Issue: For python modules that use numpy's C API, the dependency bounds defined by pin_compatible('numpy') are invalid.

In short, I wonder about the goal of setting a minimum version of numpy that is quite old (https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml#L426-L428 ). If the goal is to allow pure python packages that use numpy to have a convenient method to set the numpy version range then this should work fine. However, this does not work for python modules that use the numpy C API. This is due to that API being versioned (c.f., https://github.com/numpy/numpy/blob/464f79eb1d05bf938d16b49da1c39a4e02506fa3/numpy/core/setup_common.py#L35-L44 ). Currently, any package using the numpy C API and pin_compatible('numpy') will not actually be compatible with the numpy version range produced (numpy >=1.9.3,<2.0a0 and see the aforementioned bioconda issue for a real-world example).

So if it's recommended that pin_compatible('numpy') be used by packages using the numpy C API, then I would suggest that the minimum version be bumped to 1.14 and that whoever takes on the responsibility of bumping the numpy version used by conda-forge takes care that this is bumped in a coordinated manner. One might also set a maximum version, since it's likely that a future 1.* version of numpy will once again change its API.

If it's not recommended that pin_compatible('numpy') be used by packages using the numpy C API, then that's fine and projects like bioconda will want to mention that in the documentation. This would be unfortunate, since it makes coordinated package upgrades difficult, but so it goes.

Xref: bioconda/bioconda-recipes#10671
Xref: bioconda/bioconda-recipes#10876

Appears that the history of x264 includes annual SONAME changes and a fair bit of breakage. Would be good to work out some sensible pinning of x264. This will impact ffmpeg.

Independently the API/ABI tracker is lagging a bit. Have asked that it be updated in issue ( lvc/upstream-tracker#43 ).

ref: https://abi-laboratory.pro/tracker/timeline/x264/

cc @conda-forge/x264 @conda-forge/ffmpeg

recently we see problems arising from updating an environment as an incompatible version of tbb is pulled in. I guess tbb should be pinned to avoid this problems.

I think it's better to pin vtk as much as possible:
vtk: min_pin="x.x.x" max_pin="x.x.x"

occt should be ok with this:
occt: min_pin="x.x" max_pin="x.x"

As found here for example: https://github.com/conda-forge/harfbuzz-feedstock/blob/master/recipe/meta.yaml#L32

There was some discussion in the original PR at staged-recipes about whether ipython needed to have versions in the pinning file and if so how they should be limited. Adding this issue to the feedstock so that we can finish the discussion here and come to some resolution.

Current pinnings shown below:

cc @msarahan @isuruf @mingwandroid

We should hold off until we have all the changes we want. However we should make sure to bump the version as this is due for another release to get all the latest pinnings included.

cc @isuruf

The ABI/API report for jsoncpp shows it removing symbols on patch releases. So not only should it be pinned, but it should be pinned tightly to avoid breakage.

ref: #7 (review)

cc @dougalsutherland

• arpack
• boost
• boost_cpp
• bzip2
• cairo
• curl
• dbus
• expat
• ffmpeg
• flann
• fontconfig
• freetype
• gsl
• gstreamer
• gst_plugins_base
• gdal
• geos
• giflib
• glib
• glpk
• gmp
• harfbuzz
• hdf4
• hdf5
• icu
• jpeg
• json_c
• krb5
• libblitz
• libdap4
• libevent
• libffi
• libgdal
• libiconv
• libkml
• libmatio
• libnetcdf
• libpcap
• libpng
• libprotobuf
• librdkafka
• libssh2
• libsvm
• libtiff
• libwebp
• libxml2
• lz4_c
• lzo
• metis
• mkl
• mpfr
• ncurses
• netcdf_cxx4
• netcdf_fortran
• nettle
• numpy
• openblas
• openjpeg
• openssl
• pango
• perl
• pixman
• poppler
• proj4
• python
• pyqt
• qt
• readline
• r_base
• scipy
• snappy
• sox
• sqlite
• sundials
• tk
• vc
• vlfeat
• xerces_c
• xz
• zeromq
• zlib - conda-forge/zlib-feedstock#18
• zstd

cc @conda-forge/core

@jakirkham commented on Thu Sep 07 2017

Seems we are pinning gobject-introspection in some cases and not others. Should it be pinned? If so to what? FWIW here is the ABI report.

@jakirkham commented on Thu Sep 07 2017

cc @ocefpaf @pkgw @ccordoba12

@pkgw commented on Fri Sep 08 2017

Looks like the ABI has been quite stable, which I think is something we can expect going forward since the GLib/Gtk+ folks are generally pretty careful about that stuff. In my personal packages I generally pin things "just in case" but if that adds to hassles on the conda-forge end, I don't think pinning is actually necessary.

@jakirkham commented on Sun Dec 31 2017

Maybe just require 1.45.3 or greater as that is the last time a symbol was added?

@pkgw commented on Tue Jan 02 2018

Sure, that seems like a fine policy.

cc @conda-forge/core, @conda-forge/r-base

For new compilers, r 3.4.1 should be dropped.

ref: #7 (review)

Issue:

When I run conda smithy rerender I get

Traceback (most recent call last):
  File "/Users/wfspotz/anaconda3/bin/conda-smithy", line 10, in <module>
    sys.exit(main())
  File "/anaconda3/lib/python3.6/site-packages/conda_smithy/cli.py", line 275, in main
    args.subcommand_func(args)
  File "/anaconda3/lib/python3.6/site-packages/conda_smithy/cli.py", line 183, in __call__
    exclusive_config_file=args.exclusive_config_file)
  File "/anaconda3/lib/python3.6/site-packages/conda_smithy/configure_feedstock.py", line 892, in main
    exclusive_config_file, cf_pinning_ver = get_cfp_file_path(r, error_on_warn)
  File "/anaconda3/lib/python3.6/site-packages/conda_smithy/configure_feedstock.py", line 867, in get_cfp_file_path
    check_version_uptodate(resolve, "conda-forge-pinning", cf_pinning_ver, error_on_warn)
  File "/anaconda3/lib/python3.6/site-packages/conda_smithy/configure_feedstock.py", line 809, in check_version_uptodate
    raise RuntimeError("{} Exiting.".format(msg))
RuntimeError: conda-forge-pinning version in root env (2018.07.01) is out-of-date (2018.07.18). Exiting.

When I do conda upgrade conda-forge-pinning I get

Solving environment: done

# All requested packages already installed.

$ conda list
# packages in environment at /anaconda3/envs/py2.7:
#
# Name                    Version                   Build  Channel
anaconda                  custom           py27h2cfa9e9_0
appnope                   0.1.0                    py27_0    conda-forge
asn1crypto                0.24.0                     py_1    conda-forge
atomicwrites              1.1.5                     <pip>
attrs                     18.1.0                    <pip>
backports                 1.0                      py27_1    conda-forge
backports.shutil_get_terminal_size 1.0.0                      py_3    conda-forge
backports_abc             0.5                      py27_0    conda-forge
blas                      1.0                         mkl
bleach                    2.1.3                      py_0    conda-forge
boost                     1.67.0           py27h3e44d54_0    conda-forge
boost-cpp                 1.67.0               h3a22d5f_0    conda-forge
bzip2                     1.0.6                         1    conda-forge
ca-certificates           2018.4.16                     0    conda-forge
certifi                   2018.4.16                py27_0    conda-forge
cffi                      1.11.5                   py27_0    conda-forge
chardet                   3.0.4                    py27_2    conda-forge
conda                     4.5.8                    py27_1    conda-forge
conda-env                 2.6.0                         0    conda-forge
conda-forge-pinning       2018.07.18                    0    conda-forge
configparser              3.5.0                    py27_0    conda-forge
cryptography              2.2.1            py27hdffb7b8_1    conda-forge
decorator                 4.3.0                      py_0    conda-forge
doxygen                   1.8.14                        0    conda-forge
entrypoints               0.2.3                    py27_1    conda-forge
enum34                    1.1.6                    py27_1    conda-forge
funcsigs                  1.0.2                     <pip>
functools32               3.2.3.2                  py27_2    conda-forge
futures                   3.2.0                    py27_0    conda-forge
html5lib                  1.0.1                      py_0    conda-forge
icu                       58.2                 hfc679d8_0    conda-forge
idna                      2.7                      py27_2    conda-forge
intel-openmp              2018.0.3                      0
ipaddress                 1.0.22                     py_1    conda-forge
ipykernel                 4.8.2                    py27_0    conda-forge
ipython                   5.7.0                    py27_0    conda-forge
ipython_genutils          0.2.0                      py_1    conda-forge
ipywidgets                7.2.1                    py27_1    conda-forge
jinja2                    2.10                       py_1    conda-forge
jpeg                      9c                   h470a237_0    conda-forge
jsonschema                2.6.0                    py27_1    conda-forge
jupyter                   1.0.0                      py_1    conda-forge
jupyter_client            5.2.3                      py_1    conda-forge
jupyter_console           5.2.0                    py27_0    conda-forge
jupyter_core              4.4.0                      py_0    conda-forge
libffi                    3.2.1                         3    conda-forge
libgfortran               3.0.0                         0    conda-forge
libiconv                  1.15                 h470a237_1    conda-forge
libpng                    1.6.34               ha92aebf_1    conda-forge
libsodium                 1.0.16                        0    conda-forge
m4                        1.4.18                        0    conda-forge
markupsafe                1.0                      py27_0    conda-forge
mistune                   0.8.3                    py27_1    conda-forge
mkl                       2017.0.4             h1fae6ae_0
more-itertools            4.2.0                     <pip>
mpi                       1.0                     openmpi    conda-forge
nbconvert                 5.3.1                      py_1    conda-forge
nbformat                  4.4.0                    py27_0    conda-forge
ncurses                   5.9                          10    conda-forge
notebook                  5.5.0                    py27_0    conda-forge
numpy                     1.13.1                   py27_0
openblas                  0.2.20                        8    conda-forge
openmpi                   3.1.0                h26a2512_3    conda-forge
openssl                   1.0.2o                        0    conda-forge
pandoc                    2.2.1                hde52d81_0    conda-forge
pandocfilters             1.4.2                      py_1    conda-forge
pathlib2                  2.3.2                    py27_0    conda-forge
pcre                      8.41                          1    conda-forge
pexpect                   4.6.0                    py27_0    conda-forge
pickleshare               0.7.4                    py27_0    conda-forge
pip                       9.0.3                    py27_0    conda-forge
pluggy                    0.6.0                     <pip>
prompt_toolkit            1.0.15                   py27_0    conda-forge
ptyprocess                0.6.0                    py27_0    conda-forge
py                        1.5.4                     <pip>
pycosat                   0.6.3                    py27_0    conda-forge
pycparser                 2.18                       py_1    conda-forge
pygments                  2.2.0                      py_1    conda-forge
pyopenssl                 18.0.0                   py27_0    conda-forge
pypandoc                  1.4                        py_1    conda-forge
pyqt                      5.6.0            py27h8210e8a_6    conda-forge
pysocks                   1.6.8                    py27_1    conda-forge
pytest                    3.6.3                     <pip>
python                    2.7.15                        0    conda-forge
python-dateutil           2.7.3                      py_0    conda-forge
pyzmq                     17.1.0           py27hae99301_0    conda-forge
qt                        5.6.2                h9e3eb04_4    conda-forge
qtconsole                 4.3.1                    py27_0    conda-forge
readline                  7.0                           0    conda-forge
requests                  2.19.1                   py27_1    conda-forge
ruamel_yaml               0.15.44          py27h470a237_0    conda-forge
scandir                   1.7                      py27_0    conda-forge
send2trash                1.5.0                      py_0    conda-forge
setuptools                40.0.0                   py27_0    conda-forge
simplegeneric             0.8.1                      py_1    conda-forge
singledispatch            3.4.0.3                  py27_0    conda-forge
sip                       4.18                     py27_1    conda-forge
six                       1.11.0                   py27_1    conda-forge
sqlite                    3.20.1                        2    conda-forge
swig                      3.0.10                        2    conda-forge
terminado                 0.8.1                    py27_0    conda-forge
testpath                  0.3.1                    py27_0    conda-forge
tk                        8.6.7                         0    conda-forge
tornado                   5.1                      py27_0    conda-forge
traitlets                 4.3.2                    py27_0    conda-forge
urllib3                   1.23                     py27_0    conda-forge
wcwidth                   0.1.7                      py_1    conda-forge
webencodings              0.5.1                    py27_0    conda-forge
wheel                     0.31.1                   py27_0    conda-forge
widgetsnbextension        3.2.1                    py27_0    conda-forge
xz                        5.2.3                         0    conda-forge
yaml                      0.1.7                         0    conda-forge
zeromq                    4.2.5                hfc679d8_3    conda-forge
zlib                      1.2.11               h470a237_3    conda-forge

$ conda info

     active environment : None
            shell level : 0
       user config file : /Users/wfspotz/.condarc
 populated config files : /Users/wfspotz/.condarc
          conda version : 4.5.8
    conda-build version : not installed
         python version : 2.7.15.final.0
       base environment : /anaconda3/envs/py2.7  (writable)
           channel URLs : https://conda.anaconda.org/conda-forge/osx-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://repo.anaconda.com/pkgs/main/osx-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/free/osx-64
                          https://repo.anaconda.com/pkgs/free/noarch
                          https://repo.anaconda.com/pkgs/r/osx-64
                          https://repo.anaconda.com/pkgs/r/noarch
                          https://repo.anaconda.com/pkgs/pro/osx-64
                          https://repo.anaconda.com/pkgs/pro/noarch
          package cache : /anaconda3/envs/py2.7/pkgs
                          /Users/wfspotz/.conda/pkgs
       envs directories : /anaconda3/envs/py2.7/envs
                          /Users/wfspotz/.conda/envs
               platform : osx-64
             user-agent : conda/4.5.8 requests/2.19.1 CPython/2.7.15 Darwin/16.7.0 OSX/10.12.6
                UID:GID : 21946:20
             netrc file : None
           offline mode : False

@jakirkham commented on Thu Feb 08 2018

Trying to figure out how we should be pinning gettext. While there don't appear to be that many breaking changes. It does appear the SONAME has changed a few times in recent history. Posting the API/ABI Report here for reference. Pinnings in the org currently vary from none at all, to setting some lower bound in build/run`, to pinning to an exact version. Thoughts on how to standardize this?

cc @conda-forge/gettext @conda-forge/core

@isuruf commented on Thu Feb 08 2018

changing of soname in 0.19.8 was a mistake which was reverted in 0.19.8.1, so there's no need to pin.
Defaults on the other hand has released some R packages compiled with 0.19.8 leading to shared library missing errors. I've reported it to them, but no luck getting them to change.

Would be good to pin libsecret. Looks like 0.18 up is ok, but things break on minor versions.

cc @nehaljwani

ref: https://abi-laboratory.pro/?view=timeline&l=libsecret

It would seem appropriate to me to have an environment variable PIP_INSTALL_FLAGS that contains all the default flags we would like maintainers to include in their builds

It would look something like this

PIP_INSTALL_FLAGS=--no-deps --ignore-installed --no-cache-dir -vvv

(and maybe and an other flag as discussed here conda-forge/pip-feedstock#21 )
and allow the recipe to look like

{{ PYTHON }} -m pip install . {{ PIP_INSTALL_FLAGS }}

and taking it one step further

{{ PIP }} install . {{ PIP_INSTALL_FLAGS }}

with PIP=python -m pip

I'm not sure if hiding --no-deps parameter is useful for the general audiance as it is quite important.

Issue:
I would like to have json-c pinning updated to (include) 0.13.1.

Why:
0.13.1 is built for all three architectures, linux, osx and windows.

Possible workarounds I can see if changing the default pin is too much at this moment.

• Pin json-c to 0.13.1 only for Windows now. This should be fine since the library did not exist before.
• Create a backport of the 0.13.1 windows build scripts to 0.12 feedstock and rebuild.

Should we pin NTL to 10.5 10.3? That would fix conda-forge/ntl-feedstock#6.

Only version 1.0 of libwebp is migrated to the new compilers, but it is pinned to 0.5. This leads to problems like here: conda-forge/libgd-feedstock#25. It looks like we either have to move the pin or migrate libwebp 0.5 as well.

Any preferences?

@msarahan, what do you think about adding something like

pin_run_as_build:
  gmp:
    max_pin: x
    min_pin: x.x.x

This would mean that if gmp 6.1.2 was used at build time, then >=6.1.2,<7 will be used at runtime, right?

Would be great to include some sort of pinning for Tesseract. Requesting info for the tracker in issue ( lvc/upstream-tracker#58 ).

cc @conda-forge/tesseract

perl pinning currently is:

perl:
  max_pin: x.x

however perl packages are built/installed on a directory with the minor version included, example:

$ tar -jtvf perl-sys-cpu-0.61-pl522h470a237_2.tar.bz2 | grep site_perl

 lib/perl5/site_perl/5.22.0/x86_64-linux-thread-multi/auto/Sys/CPU/.packlist
 lib/perl5/site_perl/5.22.0/x86_64-linux-thread-multi/Sys/CPU.pm
 lib/perl5/site_perl/5.22.0/x86_64-linux-thread-multi/auto/Sys/CPU/CPU.so

so far this hasn't been a problem because we haven't had a minor update on the perl package, but I believe its important to get the pinning right to avoid installing mismatched packages on the future.

ping @conda-forge/bioconda-recipes , @conda-forge/perl

Currently gsl is unpinned. Though according to its ABI/API report, it shouldn't be. We should add it to the list with some reasonable pinning to start.

cc @conda-forge/gsl

There is a gcc7 label for one of the conda-forge-pinning packages. Is this significant somehow?

As per h5py-feedstock #35. It looks like the upgrade to HDF5 1.10.3 may have been a bit premature, as the h5py test suite fails when built against it.

CC @jakirkham .

In several places I've seen a link to the following wiki:

https://github.com/conda-forge/staged-recipes/wiki/Pinned-dependencies

But every time I go there it's empty. Is this a deprecated wiki page or a page that's waiting to be built?

blosc should probably be pinned. Not sure on its compatability; have asked at lvc/upstream-tracker#30.

In conda-forge/libhwloc-feedstock#18 I suggested to add run_exports for libwloc - however their ABI versioning stability depends on the major version:

1.11 (now called ultra stable) has had same ABI version 6 since 1.4.

2.0 is much more in flux with version 2.0.0 having libhwloc.so.12 compared to libhwloc.so.15 in patch update 2.0.2.

Of course libhwloc is about reporting hardware, so minor version changes could also be not affecting ABI but add new capabilities, I have not looked into that in great details. It should be of less importance now as any 1.x packages should be able to use the latest 1.11 release and since that major is now in stable maintenance mode upstream.

Should libhwloc pinning be added here to conda-forge-pinning-feedstock or to run_exports in libhwloc-feedstock?