Navigation Menu

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

QGIS 3.0.1 #353

Closed
wants to merge 1 commit into from
Closed

QGIS 3.0.1 #353

wants to merge 1 commit into from

Conversation

3nids
Copy link
Collaborator

@3nids 3nids commented Apr 14, 2018

No description provided.

@kbevers
Copy link
Member

kbevers commented Apr 14, 2018

I guess you've based this on the formula from the qgis-dev tap. I think that is a good starting point to get this rolling. Thank you very much for working on this!

Just a heads-up for the long-term maintenance of the QGIS formulas in case you are not already aware. It seems the homebrew project is moving towards only supporting command line applications and want to deal with GUI applications as casks instead. I don't know what the implications of moving QGIS to a cask based install but it seems to be the right thing to do in the future.

@nickrobison
Copy link
Collaborator

Awesome!

I think one issue with this formula is that the qt-5.7 formulae won’t build correctly because there’s no qt@5.7 formula. I’m trying to create one, but the compilation is failing for me.

Which version of qt does QGIS require, could we try bumping to 5.9 or something?

@kbevers
Copy link
Member

kbevers commented Apr 15, 2018

There was a request on the qgis-dev list recently about bumping the osgeo4w qt packages to either 5.9 or 5.10, so I would guess that upgrading to 5.9 would be okay.

@nickrobison
Copy link
Collaborator

@kbevers Sounds great, I'll try to get those bumped and see what we can do.

@smellman
Copy link

@3nids I just update for supports venv (qgis/homebrew-qgisdev#67), please update your PR.
Also I notice my code support only Homebrew's gdal and not support osgeo4mac's gdal because my environment depends Homebrew's gdal. This mean, this formula doesn't support grass7.
If osgeo4mac's gdal2 can share with Homebrew's gdal, I will try osgeo4mac's version for support grass7. (but I don't know about grass)

@3nids
Copy link
Collaborator Author

3nids commented Apr 17, 2018

@smellman thanks a lot for this.
Would like to push your changes here (can be a new PR) so you don't loose credit and you can work directly on the formula?
I think we should build upon our own gdal2 because there is more configuration available.
Although, an effort to push our config to homebrew core would be interesting too.

@luispuerto
Copy link
Collaborator

since you are discussing about gdal, can you tell me why Homebrew core isn't using gdal2 instead of gdal?

@luispuerto
Copy link
Collaborator

another comment about @kbevers comment about brew linkapps, why don't we move the app directly to /Applications and then create a symbolic link on the cellar just in case the app in needed there?
I usually do that, since the app in the cellar, isn't really accesible.

@kbevers
Copy link
Member

kbevers commented Apr 17, 2018

@luisspuerto

GDAL in homebrew-core is at version 2.2.4, the most recent.

As of homebrew 1.6 (released a week ago) the linkapps option is no longer there. The correct thing to do is to use casks for this but one step at a time.

@luispuerto
Copy link
Collaborator

luispuerto commented Apr 17, 2018

@kbevers I see that the update to the gdal version 2.2.4 was quite recent –a month ago or even lest. I'm happy to hear that they finally updated. The problem now is homebrew's formula seems not to have so many options as osgeo4mac one.

Are we finally going to merge formulas?

About Cask, I really like them and that is a partial solution. But, you can't download the source code and build your own app as we do with QGIS now here.

@kbevers
Copy link
Member

kbevers commented Apr 17, 2018

Are we finally going to merge formulas?

I would appreciate if that could happen. I am experiencing some issues when having both core and osgeo gdal installed at the same time. Some conflicts with postgis if I remember correctly. But it seems like a huge chunk of work to merge the two packages so I can understand if this is not going to happen.

About Cask, I really like them and that is a partial solution. But, you can't download the source code and build your own app as we do with QGIS now here.

Yeah, I guess you have to prepare the binary locally and upload it somewhere. Maybe there's the potential for a osgeo-casks project? There are other osgeo gui apps that could benefit from that as well.

@smellman
Copy link

@3nids I can make PR directly but I want to wait discussion for gdal2 issue.

@nickrobison
Copy link
Collaborator

@smellman I would suggest that for now, we stick with using the osgeo gdal2 formula. I would be open to discussing a future PR to merge the osgeo and core gdal formula, especially since we've been working to pull most of the extra backends and drivers out into their own formulae (see gdal2-mdb gdal2-mysql), so if we could use the core formula and simply layer additional data sources on top of that, that would be excellent. But seems a bit out of scope for upgrading to the latest qgis.

@3nids @kbevers @luisspuerto Thoughts?

Regarding the cask issue, I agree that we should definitely move in that direction, I've never worked with casks before, so it might take some time to figure out how to port to the new approach.

Does any of that make sense?

@kbevers
Copy link
Member

kbevers commented Apr 23, 2018

Does any of that make sense?

Yes! I agree that the GDAL stuff is out of scope for this PR. So is the casking of QGIS. This was a good place to mention both, though.

@luispuerto
Copy link
Collaborator

luispuerto commented Apr 23, 2018

IMHO, and without knows a lot, I think that if we can make work QGIS3 with what we have at hand right now it's much better. In the long run we can think on merge as much as we could in the core formulae.

Regarding to cask... I use them regularly and usually update them. @vitorgalvao has a really nice script that usually do it seamlessly. To return to the point, AFAIK cask is not for apps that build from source, which has a lot of sense. A Homebrew-cask would be the pre-build version of QGIS3 available on QGIS page.

This take us to the problem that right now homebrew has with the deprecation of linkapps. I never understood why that existed since it was more or less useless. Symbolic links aren't indexed by spotlight, so you couldn't launch the app from the Spotlight. For me, the way to go, and again, from the little knowledge I have and just being a user, is let QGIS here, and in the near future try to add it to the homebrew core –if we think it's better option– and after compilation of the app just copy it to /Applications creating a symbolic link on the cellar just in case the app was necessary there. I don't know if it's possible, but I think it's much better.

@cbertelli
Copy link

QGIS is not alone in missing a "missing package manager for macOS". Most Open Source GUI applications do. One of them is Inkscape. Tim Sheridan started the
caskformula/homebrew-caskformula
tap to keep formulas for them. Maybe it's a good idea.

@nickrobison
Copy link
Collaborator

Resolved with #429

@nickrobison nickrobison closed this Aug 7, 2018
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.

None yet

6 participants