Emacs: Stop :vc Hooking Into ELPA Checks

Jan 5, 2026 by Andrew McMorgan 41 views

Hey guys! Ever fiddled with your Emacs init.el and noticed something super annoying? You add a package using use-package with the :vc keyword, pointing it directly to a Git repository URL, and then BAM! On the next Emacs startup, it still pings the ELPA servers. What gives? It’s like telling your GPS to go to a specific street address, and it insists on checking the Yellow Pages first. In this article, we're gonna dive deep into why this happens and, more importantly, how to stop this unnecessary roundtrip. We’ll get your Emacs startup lean and mean, focusing only on what you actually told it to do, not on what it thinks it should do. Let's get this sorted, shall we?

The `use-package` `:vc` Keyword: What's the Deal?

So, you're probably wondering, "Why does Emacs even care about ELPA when I've explicitly told it to fetch from a Git URL using use-package's :vc keyword?" That's a totally valid question, and it boils down to how use-package and the underlying package system handle package installation and updates. When you specify :vc like this:

(use-package my-package
  :vc (:url "https://codeberg.org/user/my-repo.git"
       :branch "main"))

You’re telling Emacs, "Hey, I want my-package, and here’s the exact place to get it from – this Git repository." The :vc keyword is designed precisely for this scenario: installing packages directly from version control systems like Git, Mercurial, or Subversion. It’s a powerful feature for using development versions, forks, or packages not yet available on any public archive. It bypasses the need for a traditional package-install command in many cases, offering a more direct route to getting your desired code into Emacs. You might think this is the end of the story, that Emacs would just clone the repo and be done with it. But, as many of us have discovered the hard way, that’s often not the case. Emacs, or rather the package management system it relies on, has a default behavior that can sometimes feel like it’s overthinking things. It seems to want to double-check its usual sources, even when you’ve provided a perfectly good alternative. This behavior can lead to slower startup times, especially if your network is sluggish or if the ELPA mirrors are slow to respond. We’re talking about a potential delay every single time you launch Emacs, just for a check that might be entirely redundant given your explicit instructions. It’s frustrating, right? You’ve put in the effort to specify the source, and you expect Emacs to respect that. This article aims to shed light on this seemingly counter-intuitive step and provide you with the tools to streamline your use-package configurations, ensuring :vc does exactly what you tell it to do without any detours.

The Hidden ELPA Check: Why the Detour?

Alright, let's get to the nitty-gritty of why Emacs insists on checking ELPA even when you’ve provided a :vc URL. The core reason lies in the package system's default update and consistency checks. Emacs’s package manager (package.el) is designed to keep your installed packages up-to-date and ensure they are compatible with each other and with the Emacs version you're running. When use-package encounters a package definition, especially one that it hasn’t fully processed before (like when you first add it to your init file), it triggers certain checks. One of these checks is to see if a newer version of the package is available on the configured package archives (like MELPA, GNU ELPA, etc.). This is usually a good thing! It helps you stay current with bug fixes and new features. However, in the case of :vc, this check becomes a performance bottleneck and an annoyance. The system doesn't immediately recognize that the :vc directive is a complete, authoritative source for the package right now. Instead, it often performs a check against the archives in parallel or as a fallback. Think of it like this: you ask for a specific rare book directly from the author’s private library (:vc), but the librarian also checks the public library catalog (ELPA) to see if a copy is listed there, just in case. This dual approach aims for robustness – ensuring you have the package and that it’s potentially the latest stable version available through standard channels. But for :vc usage, this extra step is often redundant and slows down your Emacs startup. The package system's logic might not have a perfectly integrated way to say, "Nope, the user explicitly wants this VC source, so skip the ELPA check entirely for this specific package definition." It's a bit of a design quirk, or perhaps a feature that hasn't been optimized for this specific edge case in the way we'd like. The upshot is that even though you've given Emacs a direct, unambiguous instruction to get the code from a version control repository, it still performs a background query to its usual package repositories. This query can take time, depending on your network speed and the responsiveness of the ELPA mirrors. For users who frequently add or modify :vc packages, or who are sensitive to startup times, this delay can be quite irritating. It’s an unnecessary hurdle in an otherwise streamlined process.

The Solution: `use-package`'s `:demand` and `:init` Directives

Okay, so we know why it's happening. Now, let's talk about how to fix it and make Emacs skip that annoying ELPA check when using :vc. The magic words here are the :demand and :init keywords within use-package. These directives give you finer control over when and how a package is loaded and configured.

Understanding `:demand`

The :demand keyword is crucial. By default, use-package will load a package definition if any of its other keywords (like :config, :hook, :bind, or even :vc) are evaluated. However, if you set :demand to t (true), use-package will only load the package definition if it's explicitly needed. This might seem counter-intuitive at first, but when combined with :vc, it helps prevent the package system from automatically trying to check ELPA just because the package definition itself is being processed during startup. You're essentially telling use-package: "Don't even think about loading or checking this package unless something really requires it."

Leveraging `:init`

The :init keyword allows you to run code before the package is actually loaded. This is where we can be clever. Instead of letting use-package handle the :vc part directly in a way that might trigger the ELPA check, we can use :init to ensure the package is available before use-package gets too deep into its update-checking logic. A common and effective strategy is to use :init to explicitly call package-install if the package isn't already installed, and then point use-package to the local path. This approach completely sidesteps the need for use-package to consult ELPA for the source URL. Let’s look at a more concrete example:

(use-package my-package
  :ensure nil ; Important: Prevent use-package from trying to find it on ELPA automatically
  :init
  (unless (package-installed-p 'my-package)
    (package-vc-install "https://codeberg.org/user/my-repo.git"
                        :branch "main"))
  :config
  ;; Your package configuration here
  (message "my-package loaded from VC!"))

What’s happening here?

;; :ensure nil: This tells use-package not to try and ensure the package is installed via the standard package archives. This is key to preventing the ELPA ping.
;; :init: Inside this block, we use unless (package-installed-p 'my-package) to check if my-package is already installed. If it's not, we then call package-vc-install, which is the low-level function designed specifically for installing from version control. This function directly clones the repository.
;; :config: This section is for your usual package configurations, which will run after the package is installed (if it wasn't already) and loaded.

By using :init to perform the installation via package-vc-install before use-package potentially triggers any default ELPA checks, we essentially short-circuit the process. use-package then sees that the package is installed (because package-vc-install put it there) and proceeds to load and configure it. The crucial part is that the installation itself came directly from your specified VC URL, and the system doesn’t feel the need to go check ELPA for an update source because the installation was handled manually via :init.

A More Streamlined Approach (Recommended)

While the above works, we can often simplify it further by leveraging use-package's built-in capabilities more effectively. The goal is still to prevent the ELPA check, but without necessarily having to manually call package-vc-install within :init if use-package can handle it smartly.

Consider this refinement:

(use-package my-package
  :vc (:url "https://codeberg.org/user/my-repo.git"
       :branch "main")
  :demand t
  :config
  ;; Your package configuration here
  (message "my-package loaded from VC!"))

Wait, what? Isn't this what we started with?

Yes, but the addition of :demand t changes the game significantly. When :demand t is present, use-package becomes much more judicious about when it evaluates the package's dependencies and checks. The :vc directive is processed, but the loading and potential update checks associated with it are deferred until absolutely necessary. In many modern Emacs versions and with updated use-package configurations, :demand t can be enough to signal that the :vc source is the primary instruction, and the ELPA check is de-emphasized or skipped entirely for the source itself. The key is that :demand t tells use-package not to eagerly process the package definition, which in turn can prevent the default package.el update-checking mechanism from kicking in unnecessarily just because the :vc definition was encountered.

Important Note: The effectiveness of :demand t alone might vary slightly depending on your exact Emacs version, use-package version, and other package configurations. If you find the ELPA check still happens, the :init approach with package-vc-install is a more robust fallback. However, :demand t is cleaner and often sufficient.

What About `:ensure`?

You might notice the :ensure nil in the :init example. This is crucial because it tells use-package not to try and manage the package through the standard ELPA installation process. If you omit :ensure nil when using :init with package-vc-install, you might get conflicting instructions or errors. When not using the :init method, but just relying on :vc with :demand t, you generally don't need :ensure nil. use-package should understand that :vc is the primary mechanism.

By using these directives, you're instructing use-package to be smarter about package loading and installation. You tell it: "Load this only when needed, and if it’s a VC package, trust the VC source and skip unnecessary checks elsewhere." This leads to faster startups and a cleaner package management experience, especially when dealing with packages directly from Git or other version control systems.

Verifying the Fix: Check Your Startup Time

So, you've tweaked your init.el, added :demand t or implemented the :init block with package-vc-install. How do you know it actually worked? The best way is to observe your Emacs startup time and verify that the annoying ELPA ping is gone.

Step 1: Clean Up Your `init.el`

Make sure you’ve applied one of the solutions discussed. For instance, using the :demand t approach:

(use-package my-package
  :vc (:url "https://codeberg.org/user/my-repo.git"
       :branch "main")
  :demand t
  :config
  ;; Your configurations...
  )

Or, the more explicit :init method:

(use-package my-package
  :ensure nil
  :init
  (unless (package-installed-p 'my-package)
    (package-vc-install "https://codeberg.org/user/my-repo.git"
                        :branch "main"))
  :config
  ;; Your configurations...
  )

Step 2: Restart Emacs Multiple Times

First Startup: This is the most critical. Close all Emacs instances. Then, launch Emacs. Pay attention to the startup messages in the *Messages* buffer. Look for any indication that Emacs is trying to connect to or query package archives like MELPA. If you’re using the :init method, you should see the package-vc-install running if the package wasn't already installed. If you’re using :demand t, you might not see much explicit installation output unless it’s the very first time Emacs is aware of this :vc package.
Subsequent Startups: Close Emacs and reopen it. Repeat this a few times. The goal is to see if the ELPA check still occurs even after the package has been successfully installed from the VC source. Ideally, subsequent startups should be faster and should not involve any network activity related to checking ELPA for this specific package.

Step 3: Monitor Network Activity (Optional but Recommended)

If you're really keen, you can use system tools to monitor network connections. Tools like tcpdump, Wireshark, or even your operating system's built-in network monitor can show you exactly what Emacs is trying to connect to during startup. If you see outgoing connections to melpa.org, elpa.gnu.org, or other package archive domains after you've applied the fix, then the ELPA check is likely still happening.

What to Look For:

Absence of ELPA URLs: No connection attempts to MELPA, GNU ELPA, or other configured archives for the specific package you fixed. (Note: Emacs might still check for updates to other installed packages if you have automatic updates enabled, which is a separate behavior).
Faster Startup: Subjectively, Emacs should feel snappier on startup, especially if network latency was a factor.
*Messages* Buffer: Check this buffer for confirmation messages or absence of error/warning messages related to package fetching.

If you’ve applied the fix and the ELPA check is gone, congratulations! You’ve successfully optimized your Emacs configuration. You’ve told use-package to trust your explicit :vc directive and avoid unnecessary detours, making your Emacs startup leaner and meaner. It’s all about telling Emacs exactly what you want, without giving it too much room to second-guess!

Conclusion: Leaner Starts for a Happier Emacs

So there you have it, folks! We’ve tackled that head-scratcher of why Emacs, even when using use-package with the :vc keyword pointing directly to a Git repository, still insists on pinging the ELPA servers. It turns out this is a side effect of the package manager’s default diligence in checking for available updates and ensuring package consistency across all known sources. While well-intentioned, this behavior can lead to slower startup times and unnecessary network chatter, especially if you’re managing several packages this way.

The good news is that we’ve armed ourselves with the right tools within use-package: the :demand t directive and the :init block coupled with package-vc-install. By strategically employing :demand t, we can signal to use-package that the :vc source is the definitive one, often preventing the unnecessary ELPA probe. For a more robust solution, using :init to explicitly call package-vc-install before use-package proceeds further ensures that the package is installed directly from your specified URL, bypassing the ELPA check altogether. Remember to use :ensure nil when employing the :init method to avoid conflicting instructions.

Implementing these tweaks means your Emacs will start faster and more efficiently. No more waiting for redundant checks! It’s a small optimization, but in the world of customizing your Emacs environment, every bit counts towards a smoother, more responsive experience. Keep tweaking, keep optimizing, and happy Emacs-ing, guys!