Document "incompatible recipes" and "recipe overridden" warnings

[raxod502]

Issues like #263 and #324 illustrate that warnings like these:

Warning (straight): Packages "ivy" and "swiper" have incompatible recipes (:fork cannot be both nil and (:repo "andschwa/swiper"))
Warning (straight): Recipe for "swiper" has been overridden (:fork changed from nil to (:repo "andschwa/swiper"))
Warning (straight): Packages "swiper" and "ivy" have incompatible recipes (:fork cannot be both (:repo "andschwa/swiper") and nil)
Warning (straight): Packages "ivy" and "counsel" have incompatible recipes (:fork cannot be both nil and (:repo "andschwa/swiper"))
Warning (straight): Recipe for "ivy" has been overridden (:fork changed from nil to (:repo "andschwa/swiper"))

are confusing. Their meaning should be documented in the README, as well as how to fix them.

[matthew-piziak]

Yeah. I'm trying to use a specific emacs-request branch, but I'm getting an error.

Code:

(use-package request
    :straight (request :type git :host github :repo "dickmao/emacs-request" :branch "development"))

Warning:

Warning (straight): Recipe for "request" has been overridden (:files changed from ("request.el" "request-pkg.el") to nil)

[raxod502]

You need to load the request package before you load any other package that declares it as a dependency; otherwise, straight.el is being asked to load two different versions of the package in the same init-file, which it can't do (hence the warning). As per above, the warnings should be reworked to communicate this instead of the technical detail of how the discrepancy was detected.

[Luis-Henriquez-Perez]

The should be a way to do this without having to change the order of packages in your init file. Users shouldn't have to accomodate the order they want to load packages in their init file to please straight.

[raxod502]

Well... what you want is basically to have your packages all processed at the same time by straight.el, instead of one at a time as they are declared in the init-file. Because if they are processed one at a time, there is fundamentally no way to avoid this problem (you ask for package X, package X requests package Y, straight.el has to make both available right at that time, and then afterwards you request package Y' which is a different version of package Y, so straight.el is now backed into a corner). Doing bulk package declarations is a reasonable use case, and if it were the only thing we supported then many things would be simpler. I would prefer if we didn't require people to do that, though.

Feel free to open a feature request for either of:

• declare multiple packages at the same time, with such declarations guaranteed to not encounter the problem described in this issue
• defer package operations until the end of the init-file (so, with a certain option enabled, straight-use-package would no longer guarantee that a package was available after it returned), with the problem described in this issue guaranteed not to occur when the certain option is enabled

Or let me know if my analysis seems wrong, or you see another solution.