Haskell#cabal_install more robust deps resolution

[ilovezfs]

This could be made adjustable on a per formula basis, but since nothing in Language::Haskell::Cabal currently ensures only LTS configurations are used, always setting -1 (unlimited) makes sense.

[MikeMcQuaid]

Can you link to an explanation of what this does? Thanks @ilovezfs!

[ilovezfs]

@MikeMcQuaid Sure:

TL;DR http://stackoverflow.com/questions/29939644/backjump-limit-reached-change-with-max-backjumps

Option explained here:
https://github.com/haskell/cabal/blob/f0647d6da68920af9690ebcdc552252cdb967a8f/cabal-install/Distribution/Client/Setup.hs#L2241-L2242

Option used here:
https://github.com/haskell/cabal/blob/41eb7e804467940278a69e79910ab9f9bb91f775/cabal-install/Distribution/Client/Install.hs#L344-L355

Implementation details here:
https://github.com/haskell/cabal/blob/633d56dbdb475a2ad689fe8952058c936ea84ae0/cabal-install/Distribution/Client/Dependency/Modular/Explore.hs#L20-L108

[DomT4]

Are there any downsides to this being the global default?

[ilovezfs]

In general, I don't think so. The symptom would be that it takes "too long" or literally takes forever, but the build would timeout in that case during dependency resolution, so it's not like there's a mystery where the problem is.

The concern would be that this could potentially mask upstream issues where upstream really "should" change configuration to make it so that it can succeed with the default max-backjumps, which is currently 2000, but that probably goes in the saving-the-world-from-itself category, since Hackage will always be a nightmare regardless of what actions Homebrew takes.

It should be trivial to make it per formula now or later if global isn't the way you'd like to go.

[MikeMcQuaid]

@ilovezfs Read those, still don't understand what a backjump is 😀. Can you elaborate in stupid-human speak?

However, a more robust way of installing Yesod is to use LTS Haskell, so that the dependency tree is solved and tested for you by the Stackage project.

Is this an option for us, somehow?

[ilovezfs]

@MikeMcQuaid Wiki can do a better job than me, I think
https://en.wikipedia.org/wiki/Backjumping
https://en.wikipedia.org/wiki/Backtracking

Is this an option for us, somehow?

Yes, indeed.
https://www.fpcomplete.com/blog/2015/06/announcing-first-public-beta-stack
http://docs.haskellstack.org/en/stable/README.html
https://github.com/commercialhaskell/stack

Basically, brew would internally need to use the newfangled tool called "stack," which lets you do magical things like stack --resolver=lts-5.3, which causes it to use the consistent package set here:
https://www.stackage.org/lts-5.3

I also found a second solution to the git-annex build-failure, which is that passing --reorder-goals (instead of --max-backjumps=-1) allows it to succeed in forming its installation plan without running into the default backjump limit. In this particular case it also reduced the build time on this box from about 17 to 18 minutes down to about 14 to 15 minutes. However, in general, --reorder-goals has a negative influence on the performance of dependency resolution. They considered making it the default at one point, but rejected it due to the benchmarking results: haskell/cabal#1780

[MikeMcQuaid]

@ilovezfs Great, thanks. I think I'm 🆗 with this solution as-is but it would be great to try and use this stack thing for more stability in future 👍

[UniqMartin]

The symptom would be that it takes "too long" or literally takes forever, but the build would timeout in that case during dependency resolution, so it's not like there's a mystery where the problem is.

Does that mean that a user building locally from source could potentially end up with a stuck build that gives no indication on why it won't terminate? (Or are you referring to some cabal-specific timeout that would terminate the build nonetheless?)

[ilovezfs]

There are cases where the algorithm will never stop.

[MikeMcQuaid]

Could we maybe set the number to something very large instead?

[ilovezfs]

Could we maybe set the number to something very large instead?

@MikeMcQuaid The default is 2000. In the case of the current git-annex failure, it required 43,478. So maybe set it to that, and readjust it up in the future if needed?

[ilovezfs]

@MikeMcQuaid Another option is to do something like this:

      def cabal_install(*args)
        strategies ||= [ nil, "--reorder-goals", "--max-backjumps=100000" ]
        strategy = strategies.shift
        args << strategy unless strategy.nil?
        system "cabal", "install", "--jobs=#{ENV.make_jobs}", *args
      rescue RuntimeError
        raise if strategies.empty?
        retry
      end

I think it'd have to use popen if we wanted to match specifically for the backjumps error, and only retry on that.

[MikeMcQuaid]

@ilovezfs Bumping it to 100,000 seems reasonable to me.

[ilovezfs]

@MikeMcQuaid Does a magical number like that belong inline, in Library/Homebrew/config.rb, or somewhere else?

[MikeMcQuaid]

@ilovezfs Inline is fine; just add a wee comment justifying it.

[ilovezfs]

@MikeMcQuaid I refreshed the PR with 10^5 and a comment.

... a wee comment ...

Scottish shibboleth? :)

[UniqMartin]

@ilovezfs Thanks for adjusting that to a higher but still finite number of backjumps! If that solves the observed issue, I'm happy with this fix. 👍

[ilovezfs]

@UniqMartin Your wish is my command!

[UniqMartin]

A few notes for this and/or future submissions (as you're a prolific contributor by now):

• You're not doing Travis or our own CI any favor by pushing several updates to your branch in rapid succession. Maybe worth reviewing the changes locally before pushing them? (No hard feelings, just wanted to point that out in case you're not aware.)
• You might want to adjust the commit subject/message to reflect the changes.
• For a single-commit PR, it would help us if the commit subject and PR title would roughly match. Both could be a tad shorter (the goal for Git commit subjects is 50 characters) and (not directly applicable to this PR) have the form <formula>: fix <what was fixed>, as that makes the issue queue easier to scan and better aligns with our guidelines for commit subjects.

Thanks for considering these points. And thanks for the many good contributions in the recent past!

[ilovezfs]

You're not doing Travis or our own CI any favor by pushing several updates to your branch in rapid succession. Maybe worth reviewing the changes locally before pushing them? (No hard feelings, just wanted to point that out in case you're not aware.)

My apologies. Of course I review them locally first. Some typos have a way of escaping my notice until I see the text formatted on GitHub for some reason. I assumed that the CI immediately canceled a prior job for the same PR.

if the commit subject and PR title would roughly match

I've deliberately been making the PR titles use more expansive and alternate language, and keeping the commit subject titles < 50 and more narrow. So thanks for piping up because that's not been an accident.

[ilovezfs]

Isn't that policing too hard?

No. General-user security trumps power-user convenience every day and twice on Sunday. The primary FAQ for the haskell-stack formula is specifically guiding users to disable SIP, and they specifically point to Homebrew as their main means of distribution of the stack tool to Mac users. They need to get serious about being SIP compliant or accept full responsibility and distribute it themselves.

[MikeMcQuaid]

No. General-user security trumps power-user convenience every day and twice on Sunday.

👏
I filed commercialhaskell/stack#1799. Let's see what happens there.

[ilovezfs]

@MikeMcQuaid Perfect.

[zmwangx]

@ilovezfs

Homebrew also recommends messing with SIP, although it's quickly re-enabled: https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/El_Capitan_and_Homebrew.md. You could argue that there's also general user security problem there — what if the user forget to re-enable it?

Also, as I said, they are just doing users (who do run into the edge case — hopefully not too many) a favor by mentioning it in the FAQ. Otherwise it's just one issue hanging open, and people will search about it and end up with the same solution. Except more time is wasted.

[MikeMcQuaid]

@zmwangx Good point. @DomT4 I think we can remove that guide now that OS X is sufficiently updated that we never see people hitting that case any more.

[ilovezfs]

@zmwangx I'm well aware:
Homebrew/install#27
#45387

[ilovezfs]

@zmwangx Good point. @DomT4 I think we can remove that guide now that OS X is sufficiently updated that we never see people hitting that case any more.

@MikeMcQuaid That's a very good idea. People often still ask about it in IRC channel and think it's something they should/may need to do now/on update/at-some-point because of that FAQ.

[zmwangx]

Okay, objection attempt invalided I guess. Anyway, I still think it's way too paranoid. I agree that a formula should be rejected if it outright doesn't work with SIP on. But if it works 100% of the time for 95% of users, and requires a tweak 0.5% of the time for the remaining 5%, what's the point of making 95% people's lives harder? This is probably going to end in one of the following ways:

1. stack removes that SIP entry from FAQ. People will still encounter the problem, will still search about it, and will end up with the same solution, just not endorsed. There are people with worse google-fu so maintainers will get more inquiries. Outcome: time wasted, maintainers annoyed.
2. stack insists on keeping that entry in FAQ and Homebrew keeps the formula. Life goes on.
3. stack insists on keeping that entry in FAQ, and the formula is rejected from Homebrew. Feelings hurt, people (mostly users who used to install stack via Homebrew) annoyed. Then stack is again awkwardly submitted to homebrew-cask (there used to be a stack cask, I happened to be the guy who removed it since it better belongs to Homebrew). But since homebrew-cask can't handle upgrades, no one's happy.

Which outcome would you like to see? I'd go for 2, or 1 at least.

[ilovezfs]

@zmwangx None of the above. I'd like to see them remove the entry and fix any and all reliance on SIP ever being disabled by anyone at any time, whether due to DYLD_LIBRARY_PATH or any other reason. As for Homebrew Cask, it has the same standards with respect to SIP.

[MikeMcQuaid]

Agreed with @ilovezfs. This is well within their power to change; it's effectively an OS X breaking API change that they are asking people to disable security features to work around.

[zmwangx]

@ilovezfs

I'd like to see them remove the entry and fix any and all reliance on SIP ever being disabled by anyone at any time, whether due to DYLD_LIBRARY_PATH or any other reason.

Except it's not going to happen easily. According to their FAQ,

The only workaround we are aware of is disabling System Integrity Protection.

That's basically saying "we need help or it'll stay that way". If you really care so much about SIP (I don't) and you know a fix, it's well within your power to submit a patch, as always.

Also, this is not an ideal world. Even Apple vendors binaries that only work when SIP is disabled, e.g., dtrace. As I've stated more than once, disabling or not is at the user's discretion. They did make it clear that

Note that this reduces the security of your system.

[MikeMcQuaid]

That's basically saying "we need help or it'll stay that way". If you really care so much about SIP (I don't) and you know a fix, it's well within your power to submit a patch, as always.

It is. I already help Stack by maintaining Homebrew which maintains their software, though, and I don't have time to dig that deep on the implementation of a project I don't use, unfortunately.

[ilovezfs]

If you really care so much about SIP (I don't)

EOF

[zmwangx]

I don't have time to dig that deep on the implementation of a project I don't use, unfortunately.

Yeah, but then the stack project also has more important goals than hack around runtime protections that only a tiny fraction of users may ever bump into. What's so wrong about the workaround "disable SIP if you are okay with it" to an issue in which no one wants to invest time?

[MikeMcQuaid]

What's so wrong about the workaround "disable SIP if you are okay with it" to an issue in which no one wants to invest time?

I don't think Stack/Homebrew end-users are always in a good situation to weigh up the risks. If they need to use Stack and it isn't working and a guide says "follow these instructions to make it work": a lot of people (myself included) may just follow the steps without thinking too much about the consequences.

[zmwangx]

a lot of people (myself included) may just follow the steps without thinking too much about the consequences.

Yep, no doubt many people aren't interested in the details of SIP stuff and just want to have the issue at hand fixed. But are there actually consequences? Prior to El Capitan people lived peacefully with their Macs for many years... Many still do without SIP, and Homebrew does support those systems at least for now. It's not like you'll suddenly be pwned if you turn it off. To me, SIP is a nice-to-have, especially for technically-challenged general public without safe browsing habits, but policing packages that are slightly incompatible seems too much to me.

it's effectively an OS X breaking API change.

I think that's a good analogy. I'm sure there are many formulae in Homebrew that are slightly broken against OS X's APIs in certain edge cases, but they're included none the less because (1) they build; (2) they work at least most of the time. stack satisfies both criterions.

[ilovezfs]

@zmwangx You're perfectly capable of researching the answer to that question yourself in a non-rhetorical fashion, and I'm sure your department has several relevant courses on computer security if it's a topic that interests you.

[MikeMcQuaid]

This has been a good discussion but I think we've reached the end of it. Thanks for the input @ilovezfs and @zmwangx.

[DomT4]

@DomT4 I think we can remove that guide now that OS X is sufficiently updated that we never see people hitting that case any more.

Yup. I think that's fair. We can handle individual cases as we encounter them but Apple seems to have ironed out some of the earlier problems we had with SIP, and a lot of the people who were going to update to El Cap already have at this point. I'll remove it shortly.

This thread managed to triple the size of my GitHub inbox when I finally got around to checking it this afternoon, heh.

[DomT4]

dd1625a
Homebrew/install@8e6c575

[MikeMcQuaid]

@DomT4 Thanks!

[MikeMcQuaid]

They've compromised fairly well on this: commercialhaskell/stack#1799

[ilovezfs]

@MikeMcQuaid @zmwangx FYI: #49387 making stack lts cabal.config an option

[MikeMcQuaid]

Thanks again @ilovezfs!