From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.help Subject: Re: package-vc.el should not fetch all commits. Date: Tue, 05 Mar 2024 09:42:53 +0000 Message-ID: <87ttll815u.fsf@posteo.net> References: <4MaX8DWHJtqVVefdFcw4d0NbWWHGOR31FY0SDRpGk0O9hKn5J7CWuQzi8lsWx9YDdPhWoG-EfpK655MweVmsp2Lrl2IgydWCd0QAp9ntLlo=@proton.me> <8734taule1.fsf@posteo.net> <87o7bx3z0f.fsf@posteo.net> <877ciixd2e.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18223"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , help-gnu-emacs@gnu.org To: "amano.kenji" Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 05 10:43:41 2024 Return-path: Envelope-to: geh-help-gnu-emacs@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 1rhRKn-0004Zk-2D for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 05 Mar 2024 10:43:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rhRKM-0003vL-5A; Tue, 05 Mar 2024 04:43:14 -0500 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 1rhRK7-0003qG-RV for help-gnu-emacs@gnu.org; Tue, 05 Mar 2024 04:43:02 -0500 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 1rhRK5-0003C4-IV for help-gnu-emacs@gnu.org; Tue, 05 Mar 2024 04:42:59 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id BBD1A240101 for ; Tue, 5 Mar 2024 10:42:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1709631774; bh=xpnu3rfYdf0WKn4oTlz8oejcjjAuJmDrGLsvHbOD1w8=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=YYxKpJWFsMkx7bRncBPmwxE5HKJB/cEEQL1PM0TIkZqbAFZ6WbTD7rk/gDXPIMW7H 5oGMGnRG+5Wn+Qa6m67Sn7Aa45tWt2PfiycfhFgiFFwvgjokhNryUOK2qK9Dj5aZjN DjB6SVoOjGHa8P6fDgVScTwGkDJOrM+zU88ZSNhipIx2x8zu1iiVVvtseaWoSh+Sa/ 38MWXdBlMP2+bU0KhTKMJv4qY3wcFcB2eMLUkEmvUI/sFVBOYh5BGGhQpV++yuJPn8 GE9tMsyKoUiE0FL5WB4MetPoxh356SXxsncWPU7by1dAZBltj1rZYZ1yg6qOHSP4tF plkMK4Lb4vggA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4TprG54mwpz9rxK; Tue, 5 Mar 2024 10:42:53 +0100 (CET) In-Reply-To: (amano kenji's message of "Tue, 05 Mar 2024 05:17:36 +0000") OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@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_H4=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: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:146043 Archived-At: "amano.kenji" writes: > I want emacs to update all (VCS) packages. > > If package management is outsourced, I can't update all packages with one emacs command. I don't think Stefan is arguing to "outsource" package management. I'd imagine the idea would be that if you have a any Git repository, you could just clone it whatever way you want, then M-x package-use-that-clone the directory and it would be installed and managed by package.el, which should include the ability to update the package. What I am pondering, is if this should be part of package/package-vc, or if it would be better to make adjustments so that these can be flexibly extended, and then we could have a "package-git" package on ELPA that could provide the general interface that Stefan mentioned, and while one is at it, some auxiliary commands that would streamline common operations. > On Monday, March 4th, 2024 at 4:30 PM, Stefan Monnier wrote: > >> > Right, but there is no inherent problem in supporting other workflows, >> > as long as it is reasonably doable. E.g. we could add a user option >> > that could influence the arguments passed to vc-git-clone, so that one >> > can inject a --depth=1 argument, and restructure some of the package-vc >> > functionality to make it reusable for other intents (e.g. better >> > isolating the "building" from the "installing"), so that other packages >> > can make use of the logic that prepares manuals or resolves >> > dependencies. But that should probable be discussed in a bug report, >> > not here. >> >> >> But when it comes to installing from arbitrary Git repositories, I think >> a better path would be to provide commands that let `package.el` use >> a local clone, so that users can `git clone` any which way they prefer, >> and then just `M-x package-use-that-clone`. >> >> It would provide total flexibility for the users without needing endless >> options in our code to handle each and every possible detail. >> >> >> Stefan -- Philip Kaludercic on peregrine