Install more conventionally
The current move script does not work for M1 macs, or for anybody with a custom homebrew prefix. There's also no need for the extra step if the extension is exposed at a conventional location which homebrew can link into place.
Would you consider a more conventional approach for homebrew installation?
I use an Intel Mac and I tried this formula works for me 👍🏼 🚢
Hi folks, did this get seen at all?
So I am admittedly not much of a Ruby or a Homebrew aficionado, so from first blush this seems mostly okay to me. One reason we did the unconventional installation method was because from time to time, we need to installed to the non-default postgresql version. These get installed in places like postgresql@12 instead of postgresql, so our extension would be installed in the wrong place. Would this way still work if TimescaleDB does not support the default version of postgresql (usually some lag time between new PG major releases and our first release that supports it)?
Yeah I think you'd need to have timescaledb@12 etc as well to support older versions. But that would be the case now if folks had multiple versions installed, right? Is the ABI compatible; does timescale compiled with one version work with another?
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.
I just hit this issue today, as I have homebrew installed in ~/.homebrew. This patch seems like it'll fix the issue with custom homebrew prefixes.
One reason we did the unconventional installation method was because from time to time, we need to installed to the non-default postgresql version.
@sj26 I think we can keep the existing method packaging of the lib and share files but use HOMEBREW_PREFIX instead of Dir. We can also change the timescale_move.sh script to call pg_config --pkglibdir and pg_config --sharedir, so that the timescale extensions can be installed to any postgresql installation. I suppose the formula can also install the postgresql extension as well, but it'll get overridden on a postgresql update.
@RobAtticus Would this solution work?
This will fix the issue with homebrew prefixes, allows users to install timescale for different versions of postgresql, and allows users to reinstall timescale on postgresql update without having to rebuild the formula.