Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

conda packaging for holoscan latest version (3.x) #28598

Draft
wants to merge 14 commits into
base: main
Choose a base branch
from

Conversation

billysuh7
Copy link
Contributor

@billysuh7 billysuh7 commented Dec 16, 2024

Checklist

  • Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
  • License file is packaged (see here for an example).
  • Source is from official source.
  • Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
  • If static libraries are linked in, the license of the static library is packaged.
  • Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
  • Build number is 0.
  • A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
  • GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
  • When in trouble, please check our knowledge base documentation before pinging a team.

The following dependencies have been whitelisted to have the build going, but we need to provide them (or call them out as not supported) in conda. Only the checked items may be actionable.

  • "libcuda.so" # driver
  • "libgdrapi.so" # part of gdrcopy (https://github.com/NVIDIA/gdrcopy) which operates as kernel module
  • "libnvidia-ml.so" # driver
  • "libnvinfer_plugin.so" # NVIDIA's TensorRT (https://github.com/NVIDIA/TensorRT), not on conda-forge
  • "libnvonnxparser.so" # NVIDIA's TensorRT (https://github.com/NVIDIA/TensorRT), not on conda-forge
  • "*libonnxruntime.so.1.18.1" # onnxruntime conda package is there, but this particular version does not have this DSO. Higher version onnruntime package has this lib, but holoscan must use that.
  • "libtorchvision.so" # not available even in torchvision package in conda-forge. The github repo (https://github.com/pytorch/vision) discourages using libtorchvision.so from C++ code due to instability, in favor of Python APIs. Conda does provide pytorch, which torchvision depends on though.
  • "libv4l2.so" # a wrapper for video4linux2, Video for Linux 2, which is a kernel framework on the Linux operating system designed to support video device. http://git.linuxtv.org/v4l-utils.git
  • "libxpmem.so" # XPMEM, Linux Cross-Memory Attach kernel module, not available

Also, this package does not depend on MOFED because there is no MOFED available as conda package. Ref on dependencies: https://docs.nvidia.com/holoscan/sdk-user-guide/sdk_installation.html

Xref: #28623
This PR still very much WIP.

Copy link
Contributor

Hi! This is the staged-recipes linter and your PR looks excellent! 🚀

@conda-forge-admin
Copy link
Contributor

conda-forge-admin commented Dec 16, 2024

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 (recipes/holoscan/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/holoscan/meta.yaml:

  • ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.

This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/13403187480. Examine the logs at this URL for more detail.

@isuruf
Copy link
Member

isuruf commented Dec 17, 2024

Is this the same as https://github.com/nvidia-holoscan/holoscan-sdk? If so, why re-package it when it is open source?

@billysuh7
Copy link
Contributor Author

billysuh7 commented Dec 18, 2024

Is this the same as https://github.com/nvidia-holoscan/holoscan-sdk? If so, why re-package it when it is open source?

Hi @isuruf, yes holoscan-sdk is the same thing. The main reason for repackaging being difficulty associated with building from source in terms of meeting build dependencies. In the recipe we have white-listed a few dependencies that are kernel modules (libxpmem.so, libv4l2.so), cuda drivers (libcuda.so, libnvidia-ml.so) for which there is no conda package and no docker image prebuilt w/ them AFAIK.

Even with binary repackaging we have other hurdles to overcome before holoscan package can be released: conda packages that happen to be missing specific DSO files (libgdrapi.so missing in gds-tools, libonnxruntime.so.1.18.1 missing in onnxruntime 1.18.1, libtorchvision.so missing in torchvision), and then there are DSOs from a product that we don't have (yet)in conda-forge (TensorRT).

For gds-tools, onnxruntime and torchvision I will see when we can get respective owners to provide missing DSO, and for TensorRT we'll have to find out a plan for it with respect to conda.

@billysuh7 billysuh7 changed the title holoscan 2.6.0.1 conda packaging for holoscan latest version (3.x) Feb 5, 2025
Copy link
Contributor

Hi! This is the staged-recipes linter and your PR looks excellent but I have some suggestions.

File-specific lints and/or hints:

  • recipes/holoscan/meta.yaml:
    • hints:
      • It looks like you are submitting a multi-output recipe. In these cases, the correct name for the feedstock is ambiguous, and our infrastructure defaults to the top-level package.name field. Please add a feedstock-name entry in the extra section.

Copy link
Contributor

Hi! This is the staged-recipes linter and your PR looks excellent! 🚀

@billysuh7
Copy link
Contributor Author

Please ignore "XYZ in in requirements/run but it is not used" => the indicated packages are ones that holoscan team wants to declare as explicit dependencies. They are:
libnpp-dev, libcusolver, libcublas, libnvjitlink, nccl, libcusparse, libcufft, cuda-nvtx, cudnn and libcurand

cp -rv examples $PREFIX/
cp -rv lib $PREFIX/
cp -rv include $PREFIX/
cp -rv python $PREFIX/
Copy link
Member

Choose a reason for hiding this comment

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

Why are the pythons unpacked here instead of into site-package?

@@ -0,0 +1,362 @@
{% set version = "3.0.0.1" %}
{% set cuda_version = "12.6" %} # min version holoscan works with
Copy link
Member

Choose a reason for hiding this comment

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

If this is the minimum version, then why do you implement CEC such that this package can be installed with CTK 12.0 packages?

Comment on lines 29 to 36
cmake -S $PREFIX/examples \
-DCMAKE_LIBRARY_PATH=${GCC_DIR} \
-DCMAKE_C_COMPILER=$CC \
-DCMAKE_CXX_COMPILER=$CXX \
-DCUDAToolkit_INCLUDE_DIRECTORIES="$PREFIX/include;$PREFIX/${targetsDir}/include" \
-DCMAKE_PREFIX_PATH=$CONDA_PREFIX \
-DCMAKE_CUDA_COMPILER=$PREFIX/bin/nvcc \
-DCUDAToolkit_ROOT=$PREFIX
Copy link
Member

Choose a reason for hiding this comment

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

Did you try using $CMAKE_ARGS instead of manually setting all of these variables?

Copy link
Member

Choose a reason for hiding this comment

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

Also, this test takes a long time to build all the examples. Something shorter like

cmake -S $PREFIX/examples/hello_world/cpp $CMAKE_ARGS

might be more appropriate.

Comment on lines 328 to 329
run:
- {{ pin_subpackage("libholoscan-dev", exact=True) }}
Copy link
Member

Choose a reason for hiding this comment

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

Pin in both host and run when using exact pinnings, so that the packages are built in the correct order.

- cuda-version {{ cuda_compiler_version }} # [cuda_compiler_version != "None"]
run:
- {{ pin_compatible('cuda-version', max_pin='x', min_pin='x') }} # [cuda_compiler_version != "None"]
- {{ pin_subpackage("libholoscan" ~ soname, exact=True) }}
Copy link
Member

Choose a reason for hiding this comment

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

Pin in both host and run when using exact pinnings.

Comment on lines 71 to 72
- python =3.10
- rdma-core
Copy link
Member

Choose a reason for hiding this comment

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

Can we split the python artifacts into a separate output or are they part of the core functionality even when you are only using the C-API? Python is a large dependency for programs that don't use it.

Comment on lines +308 to +313
- test -L $PREFIX/lib/libucm.so
- test -L $PREFIX/lib/libucp.so
- test -L $PREFIX/lib/libucs.so
- test -L $PREFIX/lib/libucs_signal.so
- test -L $PREFIX/lib/libuct.so
- test -L $PREFIX/lib/libyaml-cpp.so
Copy link
Member

Choose a reason for hiding this comment

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

Are these third-party libraries that are being revended?

- test -f $PREFIX/bin/video_validation.py
- test -d $PREFIX/lib/cmake/holoscan
- test -d $PREFIX/examples
- test -d $PREFIX/include/3rdparty
Copy link
Member

Choose a reason for hiding this comment

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

We shouldn't be revending third party headers

- test -L $PREFIX/lib/ucx/libuct_xpmem.so
- test -L $PREFIX/lib/ucx/libucx_perftest_cuda.so

- name: libholoscan-static
Copy link
Member

Choose a reason for hiding this comment

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

The static library packages are meant to separate out optional static libraries when users have the option of linking to dynamic instead. For example, cudart vs cudart_static. In this case, this package only contains libholoviz_imgui.a and there is not an alternative shared library option? So a separate static library package is not needed.

check-glibc bin/* lib/* lib/ucx/* lib/gxf_extensions/*
find python/ -name "*.so*" | xargs -I"{}" check-glibc "{}"

cp -rv bin $PREFIX/
Copy link
Member

Choose a reason for hiding this comment

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

Why are we unpacking a redist instead of building from source when the source is available?

https://github.com/nvidia-holoscan/holoscan-sdk

Copy link
Member

Choose a reason for hiding this comment

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

I see that we already discussed this above back in December 2024.

For gds-tools, onnxruntime and torchvision I will see when we can get respective owners to provide missing DSO, and for TensorRT we'll have to find out a plan for it with respect to conda.

Have you opened issues on the feedstocks for these packages asking for the relevant libraries?

@conda-forge-admin
Copy link
Contributor

conda-forge-admin commented Feb 22, 2025

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/holoscan/meta.yaml) and found some lint.

Here's what I've got...

For recipes/holoscan/meta.yaml:

For recipes/holoscan/meta.yaml:

  • ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.

This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/13471290947. Examine the logs at this URL for more detail.

@conda-forge-admin
Copy link
Contributor

conda-forge-admin commented Feb 22, 2025

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 (recipes/holoscan/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/holoscan/meta.yaml:

  • ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.

This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/13514215908. Examine the logs at this URL for more detail.

…python -> holoscan 2) libholoscan3 -> libholoscan
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants