From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Unboxed package manager Date: Wed, 22 Mar 2023 16:42:48 +0200 Message-ID: <83zg846e53.fsf@gnu.org> References: <57668895-8EEA-44F7-BD46-9CDFAA11FD2C@gmail.com> <08b5f766ddd9da754a86@heytings.org> <08b5f766ddf4b33993cd@heytings.org> <08b5f766dd896dfbed4c@heytings.org> <83jzza6xwk.fsf@gnu.org> <08b5f766dd0f765bb1a9@heytings.org> <83edpi6vl4.fsf@gnu.org> <08b5f766dd05e9469540@heytings.org> <838rfq6mi8.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19926"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gregory@heytings.org, casouri@gmail.com, emacs-devel@gnu.org To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 22 15:43:20 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pezgM-0004x4-T1 for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Mar 2023 15:43:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pezfh-0007Mo-S4; Wed, 22 Mar 2023 10:42:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pezfg-0007Kn-C2 for emacs-devel@gnu.org; Wed, 22 Mar 2023 10:42:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pezff-000215-Ce; Wed, 22 Mar 2023 10:42:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=d/wJJGiXRqO+teJ8i8IrVbsbudTv4kWfmZvrEiCCL1Y=; b=BOSps3dtVrDz U1aTYYsgEft9buwp6z7R2frDMqrAsF8ZSD9JmuTpCZ6z5GlErnLaMDpytSanPcsJfiffdHt9BaWAD vBC/9Ow1plX6yhsTKxPMnl+ifaeTU4Uwfb7uxoeai9BvydSRAsQz0sKtcSoTrGmLBYy2M7bGdbaL7 xFRkuHp1yU12jasA6DdBXGrL/x4VqUlwpD0fcvaGneMe0Jmu7gGvVvLuIvyAUBhUWlaKNDd1Jxj5j kNeleULOakDtVboWKLbPPzUDIVdsPIio1D5F2NajCoAV40pbXnlW0edGvnsaEklCY9nHCtfcfVvPz bFndGjknk0xVDiRyjkS9yQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pezfe-00082f-IS; Wed, 22 Mar 2023 10:42:35 -0400 In-Reply-To: (message from Lynn Winebarger on Tue, 21 Mar 2023 20:48:29 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:304713 Archived-At: > From: Lynn Winebarger > Date: Tue, 21 Mar 2023 20:48:29 -0400 > Cc: Gregory Heytings , casouri@gmail.com, emacs-devel@gnu.org > > > A cache will not necessarily help, and you will pay the price of > > searching it at least once. It should be clear that enlarging the > > length of load-path is not scalable, unless we make it a hash-table of > > sorts. And I'm not sure we want this kind of complexity for such a > > hilariously marginal use case. > > Maybe 2000+ is marginal (today), but let's say someone just installs > the 300 packages available on gnu elpa. Why would someone want all 300 of them? Some of them even contradict each other, in that they implement similar features in very different ways. > Note I'm just installing > these packages, not actually loading any of them directly. Exactly. So this is entirely theoretical use case, not a real one. > Although if you look at something like doomemacs, people go to a lot > of trouble to make packages available on their system without paying > this overhead. The simplest approach is probably just to avoid > increasing the size of the load path when it's not really necessary. As I already said: you can simply load each package by its explicit absolute name. Poof! problem disappeared.