Remove qgis, gdal-framework: matplotlib

[commitay]

homebrew/science will be archived on (or shortly after) 1 Jan.
https://github.com/Homebrew/homebrew-science/issues/6365#issuecomment-350707678

matplotlib will likely not be accepted into homebrew/core.
Homebrew/homebrew-core#21561 (comment)

Some of the science formulas are being migrated to taps outside the Homebrew organisation but I think we should not be relying on external taps to fulfil dependancies.

The upstream for this package of qgis provides a packaged matplotlib but it also seems to require another packaged dependancy (numpy), I'm not sure if the formula numpy will satisfy this requirement. (Cask matplotlib was removed becuase of #13359)

Related issues: (probably missed a couple)

#15421, #15131, #8566, #5179

---

The steps required to install this Cask without formula dependancies make it rather complicated and difficult to provide support for if there are any issues.

Not really sure what to do with this Cask but we have a couple of weeks to decide.

[vitorgalvao]

Some of the science formulas are being migrated to taps outside the Homebrew organisation but I think we should not be relying on external taps to fulfil dependancies.

Agreed.

The steps required to install this Cask without formula dependancies make it rather complicated and difficult to provide support for if there are any issues.

Not really sure what to do with this Cask

I like to err on the side of removing. If people use it, they’ll complain and then we’ll then discuss a solution with the people that actually use the software. If it takes over a year for someone to complain, we’ll know it wasn’t that popular in the first place; otherwise we’ll think then about what we can do.

[songololo]

@vitorgalvao @commitay

If people use it, they’ll complain and then we’ll then discuss a solution with the people that actually use the software.

Hmm, hopefully 3 days is soon enough to complain! I'm missing it already.

Please can we add QGIS back somehow. It is heavily used and widely gaining favour in lieu of commercial packages like ArcMap. Having to install on Mac via a list of individual binaries is a real pain, which was greatly alleviated by being able to use homebrew and cask via:
brew cask install qgis!

Thanks.

[vitorgalvao]

@Shongololo And where’s the proposed solution? You’re skipping over the most important part of that quote.

It’s made clear in this issue that it’s a hard problem. Asking us to add it back “somehow” leaves us exactly where we were.

[songololo]

and then we’ll then discuss a solution with the people that actually use the software. If it takes over a year for someone to complain, we’ll know it wasn’t that popular in the first place

@vitorgalvao My understanding of your comment is that you're waiting for someone to complain and thus trigger a discussion. I'm triggering said discussion per your comment so forgive me if it comes across otherwise.

I have never worked under-the-hood with brew so I don't know where the discussion about the solution should start, I'm hoping someone can elucidate the issues and we can try take it from there.

[vitorgalvao]

My understanding of your comment is that you're waiting for someone to complain and thus trigger a discussion.

Correct. And I emphasise the discussion is to be with the people that actually use the software. We have nothing left to talk amongst ourselves, we need someone from outside that uses the software so as to reach an acceptable solution.

If you say “I want this” but not how we can achieve it, we have no new information and thus have nothing to work from.

[duncdrum]

I use this as well, @vitorgalvao so what is the prinicple problem with installing python dependencies via pip (v2 or v3)?

Add the caveat:
WARNING: QGIS will crash if Qt4 developer components are installed in the standard /Developer location. Either rename /Developer/Applications/Qt/Plugins or uninstall Qt before running QGIS.
(I never ran into problems with this, but its been this way for as long as i can remember)

for other uses:

brew tap osgeo/osgeo4mac
...
brew install osgeo/osgeo4mac/qgis2
...
brew linkapps osgeo/osgeo4mac/qgis2
...

Warning: `brew linkapps` has been deprecated and will eventually be removed!

Unfortunately `brew linkapps` cannot behave nicely with e.g. Spotlight using
either aliases or symlinks and Homebrew formulae do not build "proper" `.app`
bundles that can be relocated. Instead, please consider using `brew cask` and
migrate formulae using `.app`s to casks.

My main objection to removing the cask is that many sites suggest installing QGIS on macOS via homebrew-cask… not having a cask will probably confuse many people that won't come on here and comment on the PR

[vitorgalvao]

so what is the prinicple problem with installing python dependencies via pip (v2 or v3)?

It starts with the fact pip does not come with macOS. And requiring another package manager to install a single app doesn’t make sense.

My main objection to removing the cask is that many sites suggest installing QGIS on macOS via homebrew-cask

Not a valid reason. Those sites also assume that installing the cask would be trustworthy, and at the moment we cannot guarantee that.

not having a cask will probably confuse many people that won't come on here and comment on the PR

I’d rather that than people complaining they are infected with malware because we relied on a third-party tap.

As with every other cask, you’re always free to create your own tap to host it. There’s always a balance we have to strike, and so far no proposed solution outweighed the losses.

[duncdrum]

many cask rely on brew installed libraries, how is depending on brew installed python (which comes with pip) any different from that, its hombrew/core?

When or how did the officially supported source of the software for macOS become malware infected or untrustworthy?

[vitorgalvao]

many cask rely on brew installed libraries

Not many, some. They’re a definite minority.

how is depending on brew installed python (which comes with pip) any different from that, its hombrew/core?

Because it’s not just dependent on pip, but also on calling an installation from pip, meaning including a different package manager to the mix that might easily screw up the user’s configuration or be screwed up unknowingly by the user. If a user’s interaction with one package manager can screw up a package from another package manager, that’s a bad experience.

When or how did the officially supported source of the software for macOS become malware infected or untrustworthy?

Ever since it’s included in a third-party tap over which we have no control over nor do we have any reason to trust its maintainer.