drivendataorg
Update the Zamba installation instructions
Current the installation instructions require substantial expertise to follow
https://zamba.drivendata.org/docs/stable/install/
Since we have a Makefile in the repo, I wonder if we should advise users to use the Makefile.
Can you say more about which parts require substantial expertise? The pip install is a one line command. Is it the ffmpeg piece that feels trickiest?
This is based on my initial reaction, from the POV of a hypothetical user: when I read that page, I had no confidence I would be able to get a working environment set up.
The Makefile uses conda to install cudatoolkit and cudann, then pip to install the other requirements. For someone following the instructions in the docs, I wondered how they would handle this (or know to handle it). Now I see that there are instructions at the end, but I wonder if we'd want to change the order to install CUDA first?
Also, one issue that I ran into (despite my using the Makefile): I have a GPU but did not have the driver working successfully, so cudatoolkit installed successfully, but Zamba did not find my GPU. It might be good to provide instructions for users to check the configuration of the GPU (using tools like nvidia-smi) before they start the install.
Anyway, these are mostly notes as I go through the process. Whether and when we want to make changes in the docs depends in part on who we imagine is installing Zamba locally (as opposed to using Zamba cloud).
Some ideas that are relevant and may improve the situation:
- Publish a wheel when we release. Right now, pip is being pointed to a repository clone tar.gz source distribution. It doesn't make a huge difference, but it would reduce the number of steps that pip runs when a user needs to pip install zamba.
- Publish zamba to PyPI. Apparently we used to do this but stopped? Then users could just
pip install zamba. EDIT: Found #160 - Publish zamba to conda-forge. Then you could easily
conda install zambaand potentially get other dependencies like ffmpeg and CUDA-related stuff automatically.
Hi @rprabash7. Unfortunately, this issue isn't a great fit for external contributors because packaging requires access to our accounts and iteration with GitHub Actions. Also, we the maintainers don't have a great idea of what to even change here. If you have any specific ideas, we'd be happy to hear them in the issue, but it probably doesn't make sense for you to work on any changes directly. We would welcome contributions on a different, more straightforward issue though.