From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: pkg-autoloads.el vs. pkg-loaddefs.el Date: Tue, 18 Jun 2024 20:03:42 +0000 Message-ID: <87h6dqqaqp.fsf@localhost> References: <87y1adrria.fsf@localhost> <87o77zbs4j.fsf@localhost> <871q4us0l9.fsf@localhost> <87msniqhel.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23462"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 18 22:03:05 2024 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 1sJf2m-0005s8-2f for ged-emacs-devel@m.gmane-mx.org; Tue, 18 Jun 2024 22:03:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sJf29-0005fO-Sl; Tue, 18 Jun 2024 16:02:26 -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 1sJf1p-0005eW-3L for emacs-devel@gnu.org; Tue, 18 Jun 2024 16:02:05 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sJf1m-0007MZ-SP for emacs-devel@gnu.org; Tue, 18 Jun 2024 16:02:04 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 85DCC240101 for ; Tue, 18 Jun 2024 22:01:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1718740918; bh=oPoslYVnHxS6Phw8099PrU6WnoD3KyqQgg/cqqVjPOI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=juPVdGyNJuFED/v2ymIjmRHJVZpjtWSByFJV3SVHFiZphLFJg1psMvIUuYy7/m/DY poJHltNf96XaihLoflJ6yV4h24wOuPTPj7Jx8LzRUWJGyCGv4PzzO9KBd5jsJAiU/N 2NFoEVelPzd1FN4Uk6hyoFQ0mey0QRCRywF6m9K3zqwWdpkaNIQbtFdOg8Vg8q6KUP 2OfhW2ZaI+Thcm92kon7d9r55s95/Juw2yxZ2X0DaNCH8pgb0BjPcmUoPBIWp8/86K I3P7PbY3qMwX952JHQaLG1j4VyDlKe4sS6BNYUw3RviRDtV9jZNuEnP8y6hgGi2BRm e2V+iN7RNVqdw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4W3d1x4FwVz9rxR; Tue, 18 Jun 2024 22:01:57 +0200 (CEST) In-Reply-To: Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:320273 Archived-At: Stefan Monnier writes: >> I have seen configs with package-activate-all being not the first thing >> in the config. >> Some configs even do package loading in early-init. > > I currently consider these cases to be "the user's mistake". This is a very common mistake. I'd assert more - most users are not aware about the intricacies we are talking about here. They just copy-paste the code from web and get cryptic errors (and the errors from mixed installations are especially cryptic). And they do not want to know these details (or, at least, do not know where to search). And the worst thing is that mixed installation problem often manifests itself only between major releases and things "work fine" most of the time. This frustrates people a lot. > Maybe we should provide some alternative for "late activation" which > does pass the `reload` argument? Maybe. Although I am afraid that having multiple ways to activate packages will only confuse people who struggle from the problem most. > We don't do that by default in an effort to try and keep startup time > under control and also because reloading is a hack which works only > partly and can even have unpredictable effects, so it's really much > better to try and avoid it in the first place. May an approach like `require-with-check' be used here? Then, the reloading only occurs when there is a potential mixing of package versions. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at