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.devel Subject: Re: feature/package-vc has been merged Date: Sun, 06 Nov 2022 18:35:10 +0000 Message-ID: <87leoond7l.fsf@posteo.net> References: <164484721900.31751.1453162457552427931@vcs2.savannah.gnu.org> <87edupbdp0.fsf@posteo.net> <875yg1bc02.fsf@posteo.net> <878rkxgpms.fsf@posteo.net> <87sfiyk3a2.fsf_-_@posteo.net> <838rkp4ptj.fsf@gnu.org> <87zgd58i7y.fsf@posteo.net> <83k0492u5i.fsf@gnu.org> <87fsew8g18.fsf@posteo.net> <83mt941cyd.fsf@gnu.org> <87fsewp0ec.fsf@posteo.net> <837d0814c9.fsf@gnu.org> <878rkooz1o.fsf@posteo.net> <831qqg1306.fsf@gnu.org> <874jvcowzm.fsf@posteo.net> <83y1soypvx.fsf@gnu.org> <87y1song5x.fsf@posteo.net> <83v8nsyof7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7503"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 06 19:36:07 2022 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 1orkV4-0001gR-U3 for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Nov 2022 19:36:07 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1orkUR-0007pm-OH; Sun, 06 Nov 2022 13:35:27 -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 1orkUQ-0007pT-Qc for emacs-devel@gnu.org; Sun, 06 Nov 2022 13:35:26 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1orkUF-0001AI-Ud for emacs-devel@gnu.org; Sun, 06 Nov 2022 13:35:26 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id CA7C824002B for ; Sun, 6 Nov 2022 19:35:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667759713; bh=441Wqcoj/Era+i4WjhDeHaLzwHQ0AUc3L+tTDKfQBTQ=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=rndqILSafvlXwzd9PhKRPnc0XV6V+Ak4Li54fUIjVx4CB57EooxEVn6+PQ/YsSULT OsRRkEWd6k5CL+5zK4h+h+EKZ46q4CEbiCYk8BWpeZLJRoU7Wh9K0rW4fDM2BLbkex 3I4i42BQlJw6E7QoRzU0hBRNJnAEh34sewx3jRvGgGlb1F6Ojo9P3wuUCoFFeFqLx7 WTfX+DI26F5cUsFRsZ+kfbTD1x2eDZD/vLAY8wv+PB32fR2nciGU2uJ0KvVhkwAOiE kDaLBvKJadqM6ulga5EOm1cAZs8WY4FxQxiIFjlQyCK9q0k6Mr+h7GgKO8LwTsaXSh ueQfj7tWB6eRg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N53291svrz9rxK; Sun, 6 Nov 2022 19:35:10 +0100 (CET) In-Reply-To: <83v8nsyof7.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 06 Nov 2022 19:37:32 +0200") Autocrypt: addr=philipk@posteo.net; keydata= mQGNBGLfygUBDADVznbke6w0n9nE42xb+ZggbBy0IYRkkru/K+NA67523YTl2DoR2a5OMW90w7L9 KDtX2Mp34JN/6jVOSVC07VUbHVu6/exoGKixkiTpGhBPy5tUUJoxQKqLrzVQhN3fIyvg1oyHXKZm QGkUeevV0wjj4++xfjmcP235YvDh3TF8HC9t5KxIQIbhWnQm4ZyDkpWWS2CmdNttlj2+eH+51WLL bgx2bcwTmqrs079Q3hgF3yh44bBEmp9MgFjiZldOY2my0/ZSeucRxYmiM0vbJEBQgZV/MvA3gTxe 7ibV3ii7AyoYA8FiFDP98S/R2y5Nfq3ez9B7qeqtpSNseQHOU7h8Y5VV01a71ZszENAmbbwsldb9 j+HRLke7rn6mswDZl1qA/9ZFRzliFOdQtS1878XjraY+h5jfjvxaFVK23prGGVrrKv0LPWavoFUr nsjeHEZhYezBKhC2PwvRtXm01S3rkNbwm9pj0tfLSDW+1pT+6eZWptfQCXF2oEvgfKSTASUAEQEA AbQmUGhpbGlwIEthbHVkZXJjaWMgPHBoaWxpcGtAcG9zdGVvLm5ldD6JAdQEEwEKAD4WIQRxJuHe LwzjXHcL7QHyw8xRPbifZgUCYt/KBQIbAwUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAK CRDyw8xRPbifZkH+DACmCKmhrYgcv2i6dj3vRCVINaLtKUODTna/wAmP20WRKPhqvqvKNUx/wzpT aZrXIxpxOU2xawRWeHhWUktxS+W9L3xTACeR0gf5gomCxD9RuBTIohzWDkQt5rk8QwLqx5rAy5 Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:299268 Archived-At: Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: monnier@iro.umontreal.ca, rms@gnu.org, emacs-devel@gnu.org >> Date: Sun, 06 Nov 2022 17:31:22 +0000 >> >> Let's say I notice a something I would want to change/add/fix in a >> package I am using. find-function is just one way I would query Emacs >> to open up the source, then make a few changes. If I decide that these >> are worth up-streaming, it is nice to just commit them right away and >> call `package-vc-prepare-patch' to send the maintainer an email. > > How many package users do that? I know of at least one for certain, and that is me. But I have had discussions with other users from time to time where the same thing comes up. There has also been interest in alternative package managers that are principally incompatible with package.el (e.g. elpaca, straight) that advertise the fact that they allow users to easily hack on packages. > And if you think many do, why not clone the repository directly into > ~/.emacs.d/elpa/? Because that won't take care of scraping for autoloads, byte compilation and installing missing dependencies. >> All of this would only apply to packages with external `:lisp-dir's, >> which doesn't immediately interest a user/developer. Having to keep >> this in mind would pointlessly expose an internal detail of package-vc >> that I'd like to avoid. > > But it is us who introduced and support :lisp-dir. If we think it's a > leaky abstraction, we could decide not to support it. You mean as in only allowing for packages to distribute lisp code in the root directory of the repository? That would pointlessly break too many packages that decide to structure their file hierarchy for whatever reason.