Add cuspatial devcontainers

[trxcllnt]

Description

This PR adds some devcontainers to help simplify building the cuspatial C++ and Python libraries.

The devcontainers can be launched in one of two ways:

1. By clicking the "Reopen in Container" button that VSCode shows when opening the repo (or by using the "Rebuild and Reopen in Container" command from the command palette):
   
2. By using the .devcontainer/launch.sh script, which launches new VSCode windows and instances of the devcontainer.

launch.sh takes two arguments, a mode and a package manager.

The mode argument determines how the devcontainer interacts with the files on the host:

• isolated means the devcontainer doesn't mount the cuspatial source from the host, and is unique to this container instance. Use this mode if you want to launch two separate devcontainers that can each be checked out to two independent branches of cuspatial.
  • Be sure to push any commits you want to persist. Once this container is removed, any unpushed changes will be lost!
• single means the devcontainer will mount the cuspatial source from the host, but install RMM and cuDF via the package manager. This is the default option.
• unified means the devcontainer will mount rmm, cudf, and cuspatial sources from the host (and assumes RMM and cuDF are siblings to the cuspatial dir). In this mode, RMM and cuDF will not be installed, but the devcontainer will install the dependencies required to build all three.

The package manager argument can be either conda, or pip. This determines whether the devcontainer uses conda or pip to install the dependencies (the default is conda). pip is experimental/not working for normal dev, and is currently meant to aid in pip packaging work.

Examples:

# Launch a devcontainer that only mounts cuspatial and installs dependencies via conda
$ .devcontainer/launch.sh

# Launch a devcontainer that is isolated from changes on the host and installs dependencies via conda
$ .devcontainer/launch.sh isolated

# Launch a devcontainer that mounts rmm, cudf, and cuspatial from the host and installs dependencies via conda
$ .devcontainer/launch.sh unified conda

# Launch a devcontainer that is isolated from changes on the host and installs dependencies via pip
$ .devcontainer/launch.sh isolated pip

Inside the devcontainer, you can use tab-completion to explore the available commands.

# Clone one of the RAPIDS repositories into the container
$ clone-<lib_name>

# Configure the C++ CMake of <lib_name> (command accepts additional CMake arguments)
$ configure-<lib_name>-cpp

# Optionally configure the C++ CMake of <lib_name> and build the C++ (command accepts additional CMake arguments)
$ build-<lib_name>-cpp

# Optionally build the <lib_name> C++, then build the Python library (command accepts additional CMake arguments)
$ build-<lib_name>-python

You can, of course, use CMake, ninja, pip install -e . etc. directly too. The above commands are only meant as aids/shortcuts! They are simple shell scripts, and you can inspect their contents via e.g. code $(which configure-cuspatial-cpp).

All the code repos are in the $HOME dir, so cleaning is straightforward:

# Clean cuspatial C++
$ rm -rf ~/cuspatial/cpp/build

# Clean cuspatial Python
$ rm -rf ~/cuspatial/python/cuspatial/_skbuild

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[isVoid]

I worked with @trxcllnt and verified the 3 modes (single, unified and isolated) all work as expected. We noticed some issue with clangd not being able to find libcudf. Since it's rather minor, I'm approving this so that we can start enjoy the benefit of devcontainers!

[harrism]

This is very exciting. I would like to see documentation checked in with this PR. The good news is I think the description above would make a perfect readme / documentation for using the devcontainer. Can you add it to the PR, @trxcllnt ?

[trxcllnt]

I have no idea what these test failures mean, esp. since this PR doesn't change any source code. It looks like something is corrupting the runner?

[ajschmidt8]

I have no idea what these test failures mean, esp. since this PR doesn't change any source code. It looks like something is corrupting the runner?

@trxcllnt, for reference, we fixed a connectivity issue with our GPU-enabled self-hosted runners last week that was contributing to random timeouts and segfaults.

It's possible that the failures you linked were related to those connectivity issues.

[thomcom]

Working well over here.

[trxcllnt]

@thomcom rebased

[harrism]

Thanks for adding this!

[thomcom]

/merge

[trxcllnt]

@gpucibot merge

[rapids-bot]

@trxcllnt, the @gpucibot merge command has been replaced with /merge.

Please re-comment this PR with /merge and use this new command in the future.

[trxcllnt]

/merge

[thomcom]

?