conda-forge / suitesparse-feedstock

A conda-smithy repository for suitesparse.

About suitesparse-feedstock

Feedstock license: BSD-3-Clause

Home: http://faculty.cse.tamu.edu/davis/suitesparse.html

Package license: LGPL-2.1-or-later (AMD, BTF, etc.), BSD-3-clause (UFget), GPL-2.0-or-later (UMFPACK, RBIO, SPQR, GPUQRENGINE), Apache-2.0 (Metis)

Summary: A suite of sparse matrix algorithms

Development: https://github.com/DrTimothyAldenDavis/SuiteSparse

Current build status

Azure

Variant Status linux_64 linux_aarch64 linux_ppc64le osx_64 osx_arm64

Current release info

Name	Downloads	Version	Platforms

Installing suitesparse

Installing suitesparse from the conda-forge channel can be achieved by adding conda-forge to your channels with:

conda config --add channels conda-forge
conda config --set channel_priority strict

Once the conda-forge channel has been enabled, suitesparse can be installed with conda:

conda install suitesparse

or with mamba:

mamba install suitesparse

It is possible to list all of the versions of suitesparse available on your platform with conda:

conda search suitesparse --channel conda-forge

or with mamba:

mamba search suitesparse --channel conda-forge

Alternatively, mamba repoquery may provide more information:

# Search all versions available on your platform:
mamba repoquery search suitesparse --channel conda-forge

# List packages depending on `suitesparse`:
mamba repoquery whoneeds suitesparse --channel conda-forge

# List dependencies of `suitesparse`:
mamba repoquery depends suitesparse --channel conda-forge

About conda-forge

conda-forge is a community-led conda channel of installable packages. In order to provide high-quality builds, the process has been automated into the conda-forge GitHub organization. The conda-forge organization contains one repository for each of the installable packages. Such a repository is known as a feedstock.

A feedstock is made up of a conda recipe (the instructions on what and how to build the package) and the necessary configurations for automatic building using freely available continuous integration services. Thanks to the awesome service provided by Azure, GitHub, CircleCI, AppVeyor, Drone, and TravisCI it is possible to build and upload installable packages to the conda-forge anaconda.org channel for Linux, Windows and OSX respectively.

To manage the continuous integration and simplify feedstock maintenance conda-smithy has been developed. Using the conda-forge.yml within this repository, it is possible to re-render all of this feedstock's supporting files (e.g. the CI configuration files) with conda smithy rerender.

For more information please check the conda-forge documentation.

Terminology

feedstock - the conda recipe (raw material), supporting scripts and CI configuration.

conda-smithy - the tool which helps orchestrate the feedstock. Its primary use is in the construction of the CI .yml files and simplify the management of many feedstocks.

conda-forge - the place where the feedstock and smithy live and work to produce the finished article (built conda distributions)

Updating suitesparse-feedstock

If you would like to improve the suitesparse recipe or build a new package version, please fork this repository and submit a PR. Upon submission, your changes will be run on the appropriate platforms to give the reviewer an opportunity to confirm that the changes result in a successful build. Once merged, the recipe will be re-built and uploaded automatically to the conda-forge channel, whereupon the built conda packages will be available for everybody to install and use from the conda-forge channel. Note that all branches in the conda-forge/suitesparse-feedstock are immediately built and any created packages are uploaded, so PRs should be based on branches in forks and branches in the main repository should only be used to build distinct package versions.

In order to produce a uniquely identifiable distribution:

• If the version of a package is not being increased, please add or increase the build/number.
• If the version of a package is being increased, please remember to return the build/number back to 0.

Feedstock Maintainers

• @basnijholt
• @grlee77
• @jakirkham
• @jayfurmanek
• @minrk

suitesparse-feedstock's Issues

Compiling libmetis leads to problems

After I updated kwant to openblas 0.2.19|0.2.19.*, installing suitesparse leads to Segmentation fault (core dumped) when importing kwant.

getting a backtrace from the coredump I see that the segfault happens here
0x00007f6235a44934 in libmetis__CompressGraph () from /home/tinkerer/.conda/envs/anaconda/lib/libmetis.so

this reproduces the problem:

conda create --yes --copy --name test6 python=3.5
source activate test6
conda install --yes -c conda-forge kwant=1.2.2
python -c 'import kwant'
conda install --yes -c conda-forge suitesparse
python -c 'import kwant'

It's probably because suitesparse has it's own libmetis, while there is a metis-feedstock

update to 5.6.0

Issue:

Environment (conda list):

$ conda list

Details about conda and system ( conda info ):

$ conda info

@conda-forge-admin, please rerender

Additional comment:

No response

unbundle libraries?

suitesparse really is a "suite" of libraries. Until recently, most if not all of these were not available elsewhere, so packaging it as one thing makes the most sense.

With 5.4 (#54), however, suitesparse adds two new packages GraphBLAS and Mongoose, which are themselves individually packaged, versioned, and released on their own cadence, more frequent than the rest of SuiteSparse. GraphBLAS, in particular, constitutes ~90% of the build time of SuiteSparse 5.4, increasing build times from 7 minutes to over an hour. I probably wouldn't bother bringing this up, otherwise.

Choices:

• package GraphBLAS and/or Mongoose separately? (If no, no point in discussing the rest)
• should suitesparse package depend these packages? e.g. SuiteSparse 5.4 bundles GraphBLAS 2.2.2, but current GraphBLAS is 3.1.0. Is there a stability concern? If so, should the dependency pin the version exactly, or use a range?
• Should we go all the way and package the individual libraries as multiple outputs?

Issues:

• GraphBLAS has no links with the rest of SuiteSparse, so is easily separated (it's a bit weird that it's bundled, IMO, and possibly due mainly to being developed by the same group), but
• Mongoose depends on SuiteSparseConfig. The Mongoose standalone repo includes a copy of SuiteSparseConfig, so we'd have to be careful to avoid a conflict with libsuitesparseconfig.dylib. This makes it hard for SuiteSparse to depend on Mongoose, because Mongoose depends on SuiteSparse. I think this is only really feasible if we explode this recipe into having multiple outputs. For suitesparseconfig, if nothing else. mongoose appears to bundle a statically compiled suitesparseconfig, so there should be no dependency here.

windows build ?

is it possible in conda-forge ? seems defaults has windows builds of this

Package license file

Would be good to start packaging the license file here. Doesn't appear we are doing it currently.

suitesparse-feedstock/recipe/meta.yaml

Lines 67 to 72 in 6b527e5

	about:
	home: http://faculty.cse.tamu.edu/davis/suitesparse.html
	license: LGPL v2 (AMD, BTF, etc), BSD 3-clause (UFget), GPL v2 (UMFPACK, RBIO, SPQR, GPUQRENGINE), Apache 2.0 (Metis)
	summary: A suite of sparse matrix algorithms

Release 4.5.4

suitesparse 4.5.4 is now available. We should bump master to that version when we have a chance.

Investigate Windows builds

I have investigated Windows builds before and there were two takehomes:

• The Makefiles do not play well on Windows. I did not try Msys2, however, so that might actually help.
• BLAS on Windows is a huge pain.

Will investigate getting working Windows builds at some point in the future but I foresee it being painful, particularly if we haven't rectified OpenBLAS on Windows yet.

investigate setting install name

on macOS, dylibs should have their install_name (set with install_name_tool -id) set to the name that should be used to load the library. At its most specific, this should be the ABI-compatible version (*.4.dylib or *.4.5.dylib). However, the libs from suitesparse appear to set their install_name to their full name (e.g. libsuitesparseconfig.4.5.4.dylib), indicating that every patch-level release can make ABI changes.

This means that all downstream packages have to pin their dependency on suitesparse to the patch-level, because any upgrade to suitesparse, even a compatible one, will result in an image not found error on the old location:

Library not loaded: @rpath/libsuitesparseconfig.4.5.3.dylib
  Referenced from: /Users/minrk/conda/envs/petsc/lib/libslepc.3.7.dylib
  Reason: image not found

(here slepc shows an example of how this can be done: libslepc's install_name is libslepc.3.7.dylib, even though the actual file is libslepc.3.7.1.dylib)

Setting the install_name to the general (version-less) path or the ABI-compatibility version would allow for upgrading suitesparse to a compatible version without needing to rebuild the downstream package.

This should probably be reported upstream to suitesparse itself, but it can be addressed in the conda package by running install_name_tool -id ... in build.sh after make install.

Static library files should be shipped as a separate output from the shared libraries

Comment:

Please see our policy regarding not shipping static libraries together with shared libraries.

https://github.com/conda-forge/cfep/blob/main/cfep-18.md

Missing run_exports statement