PRQL / homebrew-prql

2 stars 2 forks source link

prql-query formula doesn't work on Linux atm #8

Open max-sixty opened 1 year ago

max-sixty commented 1 year ago

FYI @snth; I had a go in https://github.com/prql/homebrew-prql/pull/7, but couldn't get it working after a couple of tries, and really that dependency should be added to the formula.

Another approach would be to install the binary rather than compile it — a bit more work, but much faster for the consumer.

(or fine to not support linux, but I would vote to explicitly fail...)

snth commented 1 year ago

I'm happy to take another look at this but I'm very confused about what's actually going on.

I think your first comment linked to this run (https://github.com/prql/homebrew-prql/actions/runs/3316049427/jobs/5477387112) and while it was triggered by a prql-query PR, it seemed to be the prql-compiler test that was failing. I'm not sure if I'm reading the output correctly but it seemed to not be able to find brew which is odd?

Anyway, your current job which disabled the prql-query tests seems to be doing well (it seems to have passed on linux and atm is building the macos one).

If I can find some error messages to what the prql-query builds are failing on, then I could try and debug. If your build passes then maybe I can do it in a separate PR.


I think installing the binaries rather than building would be much better. I tried out the brew install command in a separate Ubuntu 22.04 WSL yesterday and it locked up all my cores for 10 minutes before I finally pulled the plug on it. I don't think that's the user experience we want to go for.

Any idea of how to go about that though?

snth commented 1 year ago

I merged #9 and was planning to work on #7 but I see that also got closed in the process which I wasn't expecting.

I'll see if I can track down that libclang error from #7 and find the right incantations to make it work.

max-sixty commented 1 year ago

I'll see if I can track down that libclang error from #7 and find the right incantations to make it work.

The latest failure was https://github.com/prql/homebrew-prql/actions/runs/3323612657/jobs/5494180690#step:6:29

max-sixty commented 1 year ago

I think installing the binaries rather than building would be much better. I tried out the brew install command in a separate Ubuntu 22.04 WSL yesterday and it locked up all my cores for 10 minutes before I finally pulled the plug on it. I don't think that's the user experience we want to go for.

Any idea of how to go about that though?

Yes, very much agree.

I'm not sure, but I expect there are lots of examples of this out there — lots of rust tools like rg / zellij are installed through binaries. Possible there's something that will encapsulate a lot of this for us

snth commented 1 year ago

Great idea.

I had a look at the ripgrep formula: https://github.com/Homebrew/homebrew-core/blob/master/Formula/ripgrep.rb

Which pointed me at bottles which seems to be the homebrew term for binaries: https://docs.brew.sh/Bottles

Interestingly prql-compiler is already bottled: https://github.com/Homebrew/homebrew-core/blob/master/Formula/prql-compiler.rb

Were you aware of this?

My guess from reading the old prql-compiler homebrew issues is that when prql-compiler got accepted into homebrew-core, some volunteers on their side picked it up and set up all the plumbing to do the bottling.

This post gives more guidance: https://jonathanchang.org/blog/maintain-your-own-homebrew-repository-with-binary-bottles/

It all looks a bit too involved for me right now though. I feel like my best bet at this point might just be to rather make prql-query more useful and then hope that on the back of the appeal of PRQL and pq's usefulness it gets accepted into homebrew-core and some kind soul does the bottling for us. What do you think?

max-sixty commented 1 year ago

Interestingly prql-compiler is already bottled: https://github.com/Homebrew/homebrew-core/blob/master/Formula/prql-compiler.rb

Yes! I didn't know it was bottled. There is an issue to set up an mechanism to update it on new releases, and change our docs to point to it.

It all looks a bit too involved for me right now though. I feel like my best bet at this point might just be to rather make prql-query more useful and then hope that on the back of the appeal of PRQL and pq's usefulness it gets accepted into homebrew-core and some kind soul does the bottling for us. What do you think?

No verdict on what you should work on — whatever you think will inspire you :)

In terms of making it a successful project — if you're asking for my opinion — I do think we want some reasonable way for people to try prql-query; but having that be cargo / a very slow brew install is probably OK. If we can get just a few people using it and engaging with the project, that'd be great — doesn't need to be that many at the start.

Given that it's CLI-based, people are probably going to be OK with cargo / understanding that it takes ages to compile. Maybe a signpost of "FYI it takes a while; we'll provide binaries soon" would soften that if you're concerned about it.

It's such a strong initial tool that I expect getting a few users won't be difficult, assuming we can find a catchy way of showing it (I'm already using it to replace my use of xsv, for example!). My expectation is that instead the challenge will be finding exactly how it can be helpful for people's workflow ("product-market fit") and developing in that direction.

I do think — both for prql-query and PRQL as a whole — we should not provide things that don't work — that can be demoralizing for folks — so we should remove the Linux formula. Does that sound reasonable?

WDYT? I'm keen to be helpful, both to be helpful to you personally and because I think prql-query will contribute to PRQL's success, so let me know what I can do.