From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Bj=C3=B6rn?= Bidar Newsgroups: gmane.emacs.devel Subject: Re: feature/package-vc has been merged Date: Wed, 09 Nov 2022 22:05:17 +0200 Message-ID: <87tu37sxky.fsf@thaodan.de> References: <164484721900.31751.1453162457552427931@vcs2.savannah.gnu.org> <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> <87leoond7l.fsf@posteo.net> <87mt90tyns.fsf@thaodan.de> <87o7tgfw4m.fsf@posteo.net> <87eductx0x.fsf@thaodan.de> <871qqcfs9y.fsf@posteo.net> <875yfotn63.fsf@thaodan.de> <87r0yc9g4u.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39128"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , monnier@iro.umontreal.ca, rms@gnu.org, emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 09 21:14:30 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 1osrSv-0009yi-Qp for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Nov 2022 21:14:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1osrS6-0002uT-AZ; Wed, 09 Nov 2022 15:13:38 -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 1osrKE-000111-FH for emacs-devel@gnu.org; Wed, 09 Nov 2022 15:05:30 -0500 Original-Received: from thaodan.de ([2a03:4000:4f:f15::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1osrKC-0001vi-7e; Wed, 09 Nov 2022 15:05:30 -0500 Original-Received: from odin (dsl-trebng12-b04885-76.dhcp.inet.fi [176.72.133.76]) by thaodan.de (Postfix) with ESMTPSA id 4E3D8D08D4C; Wed, 9 Nov 2022 22:05:18 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail; t=1668024318; bh=WSZzRoD9/T4TInMy2+KOPPAbuPaW6ha1/9p8xbP/wiQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=G55WSQXthqmLqem73Nmwi3iqW1Aq3C4/YnF0k33GFRGwYLzmY+qxfOHRKF3e0KMlh 845g12daZXi3pifs7iTUvoeANpad4F8Xamxoy3QHEj/EXqg4JXZ9QMLQIJshHz/f3O 2pyM0hwNhSzrT+eYFImTUFKgu8xvRt+DbRFe2nT712dvtTGtieCVg+YD0xBUBqn8Pz Yp9LHlClidw0AjReBbGhngfdbekiQXyjqB/CIPgHL1u4FQEZXAI49HjeOkzFuK374g 87q+KnSkQx89ofbMp74DoQcsBVj3rNzJjVTVyfLU1wRbR1Qlb+DNJA4tDlcbzjm+2E tcbSonUKtxE5IGtBiUcg0NFt99dTHhUo4FvCI4fcuaMiQGldST+Hz5tTyMqTVj0m/z 6Lt2sLOa/fuMtqhmx+r7O02Np2RraXQvqyeZSbFO2S/AUxW0uPCd2eTshzOP+EiJDN GuIx0EIO/cHJmdXoEmKkD+0+mEpPr3gWwVNae9rYA/KYFYLSTdKCj0hLGWQx5d81+p /tPQqtmaqAVnfaZS6iO/xkN5xDy/VcL0EoQkft8ESzMSZn7KuJvK8ViFN+mbmumgDg xIcgaAx9WudysuGcei3+Qk37+c34irXNor5lIVxSYLYsKXYtUw0u12JcYbZMnXI0mS AEYPoDQHqYg/DnWELto5d/yI= In-Reply-To: <87r0yc9g4u.fsf@posteo.net> (Philip Kaludercic's message of "Wed, 09 Nov 2022 17:44:49 +0000") Received-SPF: pass client-ip=2a03:4000:4f:f15::1; envelope-from=bjorn.bidar@thaodan.de; helo=thaodan.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 09 Nov 2022 15:13:35 -0500 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:299428 Archived-At: Philip Kaludercic writes: > Bj=C3=B6rn Bidar writes: > >> Philip Kaludercic writes: >> >>> Bj=C3=B6rn Bidar writes: >>> >>>> Philip Kaludercic writes: >>>> >>>>>> From my pov if you use the package directly from the version control >>>>>> system you need to take these specialties into account. >>>>>> Source isn't used as is but processed by the packages build-system. >>>>>> But the user also needs to take not that all the necessary tools suc= h as >>>>>> make or ninja are installed. >>>>> >>>>> Right, this is currently not supported. Theoretically for security >>>>> reasons, but security and packaging in Emacs have rarely been mutual >>>>> considerations. Adding it wouldn't be difficult, but coming up with a >>>>> sensible fallback strategy might be. >>>> >>>> Without such a system the package could be without use in many cases. >>> >>> Many is probably the word of contention here. If you take a look at >>> elpa.git:elpa-packages, you'll find only a few :make or :shell-command >>> directives, none of which are critical. nongnu.git:elpa-packages has >>> non at all. One thing I worry about, but which has also been discussed >>> here are :renames. E.g. Vertico uses these to move extensions from a >>> subdirectory to the main directory for packaging. But moving the files >>> would be registered by the VCS, and could make committing changes more >>> difficult. Maybe we could create symbolic/hard links instead of >>> renaming? >> >> Most packages work fine with if they are used in place. > > What do you mean by "in place" here? In side the repositories on source tree. >>>> I noticed recently that some external packages such as projectile where >>>> copied but not to the extend or why that they are useful. >>> >>> I am afraid I don't understand the issue you are describing. Could you >>> be more concrete? >> >> The package is copied but not as good because in the end it misses some >> features, it doesn't feel as polished. I don't have a direct example >> except missing features like no build system integration. >> It is just to bare bone. > > I am still confused as to what you are thinking about. Setting aside > :make, :shell-command and :renames, the end experienced result of > installing a package that was prepared by elpa-admin.el or one installed > using package-vc (assuming package-vc uses the revision of the latest > release) should be identical. More complex packages have a configure/prepare step, generate some lisp code, build native parts. In the case of borg you can just add additional steps to for example in my case build the emms libtag helper that isn't build if you use melpa. But you addressed that in an earlier comment.=20 >>>> For example Borg only works because of magit, epkg is almost useles >>>> without Borg. >>> >>> Just to clarify, I have never used Borg, straight, elpacaa, etc. so I >>> don't know how they work, how they are used or what terminology they >>> use. I have peeked into their source code in the past, but none of that >>> was related to the development of package-vc. >> >> That's to bad I think it very helpful to improve on such packages or >> even just adapt them instead of reinventing them. > > The point of package-vc.el is to have something that explicitly extends > package.el and works in the core, in active collaboration with ELPA. > That is why the implementation is far simpler than what others have to > do, because they are fighting an up hill battle outside of the core. There might be reasons for that.. Quite often the core packages aren't as good or just to complicated/convoluted with legacy features. Or in case of borg compared to package-vc deeper integration into git or other different features like building packages in a second instance with just borg and the package.