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

Install more conventionally #20

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Install more conventionally #20

wants to merge 1 commit into from

Conversation

sj26
Copy link

@sj26 sj26 commented May 28, 2021

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?

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.
@JuanitoFatas
Copy link

I use an Intel Mac and I tried this formula works for me 👍🏼 🚢

@sj26
Copy link
Author

sj26 commented Jul 28, 2021

Hi folks, did this get seen at all?

@RobAtticus
Copy link
Member

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)?

@svenklemm svenklemm force-pushed the master branch 2 times, most recently from 0d74467 to b38e2ad Compare August 1, 2021 17:37
@sj26
Copy link
Author

sj26 commented Aug 2, 2021

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?

@svenklemm svenklemm force-pushed the master branch 7 times, most recently from e946c9c to a331ce8 Compare August 2, 2021 10:48
@CLAassistant
Copy link

CLA assistant check
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.

@pethin
Copy link

pethin commented Jun 11, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants