R bottle options/graphics capabilities


#1

Hi all,

I do not want to annoy anyone by creating another GitHub issue on the topic so I thought I would start a discussion here instead.

The move of R to homebrew/core resulted in the loss of some optional capabilities that plenty of users badly need. I can personally get away without X11, but the lack of cairo is very frustrating to me. I see it being written off as unimportant because:

we have 10,898 installs in the last 30 days so I think the formula is proving sufficiently useful as-is without adding an X11 option

But the fact that issues about it keep opening up suggests that it was in fact useful to many. I would like to know if there is an argument to be made to change this policy which seems rather senseless from an R user’s point of view. I would like to hear reasoning against including the cairo option other than ‘people don’t use it’ since, clearly, some people use it.

#19557
#20540
… and more that I am not allowed to post.


(Mike McQuaid) #2
  • Options are not tested by CI and don’t provide binary packages. This makes them significantly more error-prone and when errors happen: the Homebrew maintainers need to deal with them.
  • Homebrew is transitioning from a build-from-source to being a binary package manager. This means we’re removing more options and, eventually, all options.
  • This option was not sufficiently widely used enough to justify being added by default.
  • Anyone can copy-and-paste the old Homebrew/homebrew-science formula into a tap and run it that way. Homebrew/homebrew-core will never be all things to all people so if you care: consider maintaining your own tap.

#3

Okay, sorry for necroposting on this - I thought maybe I could work around the problem, but I just end up in google hell every time.

Homebrew is transitioning from a build-from-source to being a binary package manager. This means we’re removing more options and, eventually, all options.

Let me start with saying that that is a fair point and pretty much the only justification needed for lack of options. At the same time, the binary R package from CRAN does have these capabilities by default. So does a binary package in Linux on my non-work laptop. Why can’t the Homebrew version?

This option was not sufficiently widely used enough to justify being added by default.

R is different things for different people, including for example students who install it to do a course and not touch it again. As far as I know (and I have searched for quite a while), the built in cairo device is the only way to get R to output figures in vector format with both custom fonts and Unicode support. As specific as that is, it’s not some obscure functionality used by 3 people but rather a basic requirement if you want to produce good-looking plots.

when errors happen: the Homebrew maintainers need to deal with them.

Is that so much worse than dealing with people complaining about their software being broken by design?

consider maintaining your own tap.

I have, but as a user-not-programmer I’m also not quite sure on how to do it so that nothing breaks and I don’t have to spend the next 2 days reading docs and googling frantically instead of doing the work I want to do with the software.

If need be, I can probably just ditch the Homebrew version altogether and install the CRAN binary (or switch to Ports, or compile from source, or…). Still, the whole point of a package manager is to provide convenience and consistency to the Mac environment. When users (multiple users, not just me) point out that a package is missing an important and common functionality, I would hope for a different response than ‘just maintain your own repo’.


(Mike McQuaid) #4

Yes.

brew cask install r-app is another option.

Diplomatically, the point and goals of Homebrew are decided by the maintainers of Homebrew. If our goals don’t align with yours: you need to either help yourself with the tools we provide (i.e. create a tap) or use a non-Homebrew solution.


#5

Sure, as a volunteer developer you can break whatever you want in your own project. But when something breaks, it also breaks your users’ workflows that not all of them have time or ability to fix on their own.

Cool, I’ll try that then. Thanks.


(Mike McQuaid) #6

Yes. Again, diplomatically, this is their problem and not our problem. https://mikemcquaid.com/2018/03/19/open-source-maintainers-owe-you-nothing/ explains this line of reasoning more.


(Seth Fore) #7

If you are still interested, there is a tap supporting all/most of the build options formerly available for the R formula including cairo. The repo is available at https://github.com/sethrfore/homebrew-r-srf or you can use the standard brew tap/install methods.


#8

Hi,

I’m using it now. Went for Cairo support without X11, works perfectly. Thanks a lot!


(Luis Puerto) #9

Hey!

I just want to give my two cents about this issue.

First of all, my outmost respect for the work that maintainers do, as @MikeMcQuaid who has been here working for us for free for really long time, and, of course, to their decisions. Even more when maintainers are everyday in the first line of battle fighting to maintain the project alive up and running for all of us, users. They usually know better since they work with the problems and practicalities day after day. For this reason, I understand their motives for some of the decisions previously explained.

However, and with all my respect, let me to dissent a little bit on some of those decisions, thoughts and policies that have been poured here.

First

I totally understand the policy about less option and in the end no options. Simplicity is a virtue and helps a lot maintainers. So go ahead. One of the reasons I use Homebrew is because I can get the best cutting edge software in the simplest way thanks to a lot of people that participate in the project —internally and externally.

Second

If you don’t get the same software, with the same capabilities, as you can get downloading the binary from the developer, why we are going to bother at all to use Homebrew to install that software. We are getting a second class version. Why don’t make the bottle exactly the same as the original developer binary???

Third

Some software have building options to accommodate people’s different necessities and that doesn’t have to be in opposition to simplicity. What is more, it can be an asset for this project, since it’s something the developer is not offering or at least easily offering.

In my case Homebrew allows me to install R with OpenBlas and OpenMP support which make my life easier and simpler with really few knowledge of how to build software on macOS. That’s something really wonderful. I’ve been praising Homebrew to all my friends and colleagues and even I’ve written a post in my blog about how to do it. My wife was able to carry out her research faster and easier thanks to that options that original developers weren’t offering just with a couple commands on terminal.

Fourth

If you think that things get really complicate and you believe they don’t fit in the “core” just try to externalize to a tap. What is more, why don’t original developers are the maintainers of that tap? It would be a wonderful way to offer their users extra capabilities to fit all their needs. And if they aren’t able to make that happen, some users can create their own taps, of course. At this moment there is no “official support” for R users that installed R with Homebrew. I don’t understand why they can’t maintain a tap to provide R to macOS in the same way they provide for Linux and provide “support”.

Fifth (and final, yeah!)

Of course open-source developers and maintainers own nothing to anyone and of course you don’t need to stand the bad manners of some few users.

However, you aren’t going to hide from users behind of a piece of paper and legalese language, do you? Even more what that is there mainly to avoid lawsuits, which I understand.

You own nothing to anyone, but you have to understand that when lots of people use what you are maintaining and working on, you decisions affect them and what they are building upon your work. So it’s reasonable that when there is a change of course and people has to rebuild their work or invest time on make things work again they get a little bit “touchy”.

You have to think also that without “users” any project, open source or commercial, is nothing. That is that way in other human ventures, from politics, ONGs, business, or government. It’s normal that wan you are relying on something, whether you paid for it or not, and that something change or disappear you get disappointed. It’s a relation that is not written down, but it’s there, and we all have to live with it and interact with others in the most assertive and emphatic way.

Post Scriptum

I’m sure that I’m forgetting and not tacking into account a lot of things and even not getting others —technical, personal, political, put-whatever-you-want-here ones. Perhaps, I’m also missing tons of threads and issues where the reasons for some decisions were explained. But I think this is how I’m sure a lot of users feel. We don’t want to burnout anyone we just want to enjoy the software in the same way you want to enjoy maintaining and developing it.

Please! to everybody involved:


(Luis Puerto) #10

besides the incredible wall of text I just wrote I want to thank @srfore for creating a tap that cover the necessities of some users out there.


(Mike McQuaid) #11

Thanks for the kind words!

Homebrew Cask installs literally the same upstream software and many people still find it useful.

If you mean the R maintainers: sure, that’s a good idea. If you mean the Homebrew maintainers: in short: because we don’t want to as we’re unable to support it to an acceptable standard.

We’re not hiding from users as we’re interacting with them daily. However, that legalese does explain the obligations (and freedoms) in the open source ecosystem pretty well.

I agree however all maintainers are users and ultimately if Homebrew is just useful to me: I continue to work on Homebrew and it has a user. Users who don’t contribute in any way to the project (and contributing can include e.g. helping other Homebrew users) do not add anything to our ecosystem.

Thanks again. We want you to enjoy it too but there’s things that you want that would make us not enjoy it in providing it to you (so we don’t). That’s why we want to make taps as easy to use as possible: so someone else can.


(Luis Puerto) #12

Thanks a lot for your reply @MikeMcQuaid

If you mean the R maintainers: sure, that’s a good idea. If you mean the Homebrew maintainers: in short: because we don’t want to as we’re unable to support it to an acceptable standard.

Yeah, I meant the R developers. I don’t know how it really works on Linux repositories, but I guess the original developers are the ones in charge to put software there.


(Seth Fore) #13

You are quite welcome. I maintain the tap as much for my own purposes as anyone else. Nevertheless, I’m pleased it’s been of use to you and others.

I intend to keep the formula as up-to-date and compatible with various dependencies as I can and my ability allows. As issues with the tap/formula arise in the future, the best way to expedite a resolution will be to direct them to me at the formula’s Github repository (e.g., open an issue or submit a pull request).

Ultimately, it’s the Homebrew crew that deserves the thanks for providing access to a wide range of programs and in particular for providing a highly customizable way to use and share them.


(Andrew Janke) #14

Hi y’all. Professional data-analysis developer and former Homebrew maintainer here, dabbler in R.

My two cents: remember Homebrew is mostly about getting formerly-Linux and other mostly command-line programs running on Mac OS X. The R build with cairo support is getting closer to an interactive GUI application, which is better supported by the native app distributed by CRAN (and installed by brew cask r-app like Mike says), and not a great fit for homebrew-core.

That being said, if there’s actually a user base for it, I might be able to help out with keeping R + cairo + graphics running in a separate Tap like @srfore is maintaining. Feel free to @-mention me in issues there if you want help; I’m apjanke on GitHub.


(Luis Puerto) #15

That sounds great @apjanke! I know that some apps are in a grey area. Also, and as I mention before, the problem some of us have with r-app is it isn’t optimize with openblas and when you compare a build with openblas and openmp support with R from CRAN there is no comparison. openblas is far superior.

It would be great if we can create a Tap for there and I would love to give a hand helping maintaining it. I don’t know if I have all the technical knowledge to do it, thought. It would be even greater if we can get people from R development involve in the long run.