Add installation instructions for conda

[janjagusch]

Rill is now available on Conda-Forge: https://prefix.dev/channels/conda-forge/packages/rill

This PR extends the documentation to add Conda installation instructions.

Also, if any of the Rill maintainers would like to help maintain the Rill Conda-Forge feedstock, please add yourself as recipe maintainer here.

[begelundmuller]

Hey @janjagusch, will the conda install path stay in sync with our latest release here on Github? We can't commit to maintaining the feedstock from our side, but would be happy to merge this if it will automatically stay in sync with our releases.

[begelundmuller]

Something else – I just added a new section for "alternative install options" to install.md in this PR. Do you mind syncing your PR and moving the Conda instructions to a subheading in this new section? Thanks!

[janjagusch]

Hey @janjagusch, will the conda install path stay in sync with our latest release here on Github? We can't commit to maintaining the feedstock from our side, but would be happy to merge this if it will automatically stay in sync with our releases.

To publish a package to Conda-Forge, you need to build it from source. So, as long as the build process doesn't change between releases, we can keep the Rill feedstock up-to-date with minimal effort. If it changes, it would be good to have the help of a Rill maintainer available.

[begelundmuller]

Hey @janjagusch, I took a look at the feedstock, and have some comments:

1. The build produced by running make directly is not a proper release build – e.g. it does not configure the correct version metadata (for rill --version and for upgrade notifications). We use https://github.com/goreleaser/goreleaser for the production builds, and to avoid divergent configuration, we want to only distribute binaries produced by it.
2. Using duckdb_use_lib and installing DuckDB separately means Rill is no longer a static binary. We don't do regular testing of such a configuration, and it opens up some new error scenarios that users don't otherwise need to worry about (e.g. DuckDB version mismatch, or incorrectly configured library search paths). I wouldn't be comfortable recommending that as an official installation path, though in theory it should work in most cases (as long as the DuckDB dependency is upgraded at the same cadence as Rill).

[janjagusch]

The build produced by running make directly is not a proper release build – e.g. it does not configure the correct version metadata (for rill --version and for upgrade notifications). We use https://github.com/goreleaser/goreleaser for the production builds, and to avoid divergent configuration, we want to only distribute binaries produced by it.

Thanks for pointing that out. I working on fixing the version metadata in conda-forge/rill-feedstock#4.

Using duckdb_use_lib and installing DuckDB separately means Rill is no longer a static binary. We don't do regular testing of such a configuration, and it opens up some new error scenarios that users don't otherwise need to worry about (e.g. DuckDB version mismatch, or incorrectly configured library search paths). I wouldn't be comfortable recommending that as an official installation path, though in theory it should work in most cases (as long as the DuckDB dependency is upgraded at the same cadence as Rill).

I understand your concern. Packages on Conda-Forge are usually dynamically linked. So the Rill binary on Conda-Forge will differ from the official one that you release. It's fine for me if you don't want to recommend it as an offical installation channel yet.