Hi all,

I just discovered a bug in this advice that I suggested earlier in this thread.. I needed to fix the order of packages in the new-ret list that is returned. The bug was that the order of pkgs in new-ret was flipped compared to that in orig-ret.. so I needed to flip it back using reverse.

So just for record, here is the fixed function:

;; http://emacs.stackexchange.com/a/26513/115
(defun modi/package-dependency-check-ignore (orig-ret)
  "Remove the `black listed packages' from ORIG-RET.

Packages listed in the let-bound `pkg-black-list' will not be auto-installed
even if they are found as dependencies.

It is known that this advice is not effective when installed packages
asynchronously using `paradox'. Below is effective on synchronous
package installations."
  (let ((pkg-black-list '(org))
        new-ret
        pkg-name)
    (dolist (pkg-struct orig-ret)
      (setq pkg-name (package-desc-name pkg-struct))
      (if (member pkg-name pkg-black-list)
          (message (concat "Package `%s' will not be installed. "
                           "See `modi/package-dependency-check-ignore'.")
                   pkg-name)
        (push pkg-struct new-ret)))
    ;; Tue Apr 11 17:48:16 EDT 2017 - kmodi
    ;; It's *very* critical that the order of packages stays the same in NEW-RET
    ;; as in ORIG-RET. The `push' command flips the order, so use `reverse'
    ;; to flip the order back to the original.
    ;;   Without this step, you will get errors like below when installing
    ;; packages with dependencies:
    ;;   Debugger entered--Lisp error: (error "Unable to activate package ‘nim-mode’.
    ;;   Required package ‘flycheck-28’ is unavailable")
    (setq new-ret (reverse new-ret))
    new-ret))
(advice-add 'package-compute-transaction :filter-return #'modi/package-dependency-check-ignore)

On Tue, Jan 24, 2017 at 11:28 AM Thomas S. Dye <tsd@tsdye.com> wrote:

Alan Schmitt writes:

> Thank you for the suggestion, but I use Spacemacs, which in turn uses
> paradox.
>
> Why couldn't there be an org-contrib package, depending on org? So that
> way org would not be duplicated in two packages.

I've run into the same problem with Spacemacs and would welcome a
solution.

All the best,
Tom

--
Thomas S. Dye
http://www.tsdye.com
--

Kaushal Modi