cus-edit package is not found
akirak opened this issue · 11 comments
unpackaged/custom-set-at-point
function depends on cus-edit
package, which is not found in any of org-elpa
, melpa
, gnu-elpa-mirror
, and emacsmirror
. I don't know what this package is supposed to do, but it doesn't look like a good idea to load dependencies in unpackaged.el
through use-package
, because it can cause load errors. Unlike typical packages, I only need part of unpackaged.el
and not all the stuffs, so I need a way to skip the dependencies.
Hi Akira,
I don't understand. cus-edit
is part of Emacs, it's in cus-edit.el
in the lisp
directory of the Emacs source. It's part of the customization system. It has (provide 'cus-edit)
at the end of the file, so it should work in a use-package
form, and it's full of autoloads, so it should probably be loaded in your Emacs session already.
I meet the same problem, because there's (setq use-package-always-ensure t)
in my init file, and (use-package cus-edit :ensure nil)
may solve the problem.
@yunhao94 This seems strange to me. For example, this issue seems to indicate that use-package
is intended to work properly with built-in packages (technically, "features" rather than "packages"), even if :ensure
is used: jwiegley/use-package#491
@akirak @yunhao94 What exactiy is the problem you're having? Are you getting an error message?
If use-package
is trying to install an already-installed, built-in feature, that seems like a bug in use-package
which ought to be reported.
I attempt to use GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.8) of 2019-04-13
with a minimal init file like this:
;;; -*- lexical-binding: t -*-
(setq debug-on-error t)
(require 'package)
(setq package-archives '(("gnu" . "http://mirrors.tuna.tsinghua.edu.cn/elpa/gnu/")
("melpa" . "http://mirrors.tuna.tsinghua.edu.cn/elpa/melpa/")))
(package-initialize)
(unless (package-installed-p 'use-package)
(package-refresh-contents)
(package-install 'use-package))
(eval-when-compile
(require 'use-package))
(use-package cus-edit
:ensure t)
and get the following error message:
Debugger entered--Lisp error: (error "Package ‘cus-edit-’ is unavailable")
signal(error ("Package ‘cus-edit-’ is unavailable"))
error("Package `%s-%s' is unavailable" cus-edit "")
package-compute-transaction(nil ((cus-edit)))
package-install(cus-edit)
use-package-ensure-elpa(cus-edit (t) nil)
eval-buffer(#<buffer *load*> nil "/home/user/.emacs.d/init.el" nil t) ; Reading at buffer position 458
load-with-code-conversion("/home/user/.emacs.d/init.el" "/home/user/.emacs.d/init.el" t t)
load("/home/user/.emacs.d/init" t t)
#f(compiled-function () #<bytecode 0x1df989>)()
command-line()
normal-top-level()
I am using straight.el to fetch packages and get the following error on Emacs 26.2 (built with Nix):
(error "Could not find package cus-edit in recipe repositories: (org-elpa melpa gnu-elpa-mirror emacsmirror)")
signal(error ("Could not find package cus-edit in recipe repositories: (org-elpa melpa gnu-elpa-mirror emacsmirror)"))
error("Could not find package %S in recipe repositories: %S" cus-edit (org-elpa melpa gnu-elpa-mirror emacsmirror))
straight--convert-recipe(cus-edit nil)
straight-use-package(cus-edit)
I found a solution to prevent the error with straight.el. I had to override the recipe for the built-in package:
(straight-use-package '(cus-edit :type built-in))
I'm getting a bit confused now. @yunhao94's ECM doesn't involve straight
, but @akirak just said that he's using straight
. Is it part of the problem or unrelated?
Again:
If use-package is trying to install an already-installed, built-in feature, that seems like a bug in use-package which ought to be reported.
Please consider reporting a bug to the use-package
tracker.
Specifically, it seems to me that this function ought to check whether a feature is already present using featurep
. For example, (featurep 'cus-edit)
returns t
. If it checked for that, it would know not to try to install it as a package.
Ping, anyone?
I don't use the command, but both unpackaged.el and cus-edit successfully load now. I think this issue should be closed.
Thanks.