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: Wed, 09 Nov 2022 17:44:49 +0000 Message-ID: <87r0yc9g4u.fsf@posteo.net> References: <164484721900.31751.1453162457552427931@vcs2.savannah.gnu.org> <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> <87leoond7l.fsf@posteo.net> <87mt90tyns.fsf@thaodan.de> <87o7tgfw4m.fsf@posteo.net> <87eductx0x.fsf@thaodan.de> <871qqcfs9y.fsf@posteo.net> <875yfotn63.fsf@thaodan.de> 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="9735"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , monnier@iro.umontreal.ca, rms@gnu.org, emacs-devel@gnu.org To: =?utf-8?Q?Bj=C3=B6rn?= Bidar Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 09 18:45:11 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 1osp8Q-0002GI-Va for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Nov 2022 18:45:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1osp8D-0005fM-4b; Wed, 09 Nov 2022 12:44:57 -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 1osp8A-0005eT-IT for emacs-devel@gnu.org; Wed, 09 Nov 2022 12:44:54 -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 1osp88-0003vz-8I for emacs-devel@gnu.org; Wed, 09 Nov 2022 12:44:54 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 58D3C24002B for ; Wed, 9 Nov 2022 18:44:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1668015890; bh=EcS9TlIkrRkdZN995qX4B87himAGJqWjCpBmi24OWG4=; h=From:To:Cc:Subject:Date:From; b=HGexgKHYzXsonKBmhRWeDh6CMJbBcKqXhpPfCywqIEJt/waqvQcM1XnkslaK1ZLue tDkq/oNIVft24lurrAxFfAR5zumjYZDOhdrqDhlE0O1ASAUgFIf/pCsx4wF4VpqKPs 7ylBu4TfORDo6o4Fl/r9SZtM2TkFZueWciwM8aQRwOSSQBjt4/bGUkDDvjMnIVFwgV h0LHcyZDREPA2F/YscQuc2Fu+05xashTCOJ3mKyrYoKNKPwzi6Z4ffYidr5Rjbx4gq BACwkNPB3/F8QcHQ5aSPRLvmlf2q2i/1HSA42jpVKrWg9tqDYncrGX/0VH1rNDpdLp H6zfMAZoqpf9g== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N6smd3xj8z9rxH; Wed, 9 Nov 2022 18:44:49 +0100 (CET) In-Reply-To: <875yfotn63.fsf@thaodan.de> (=?utf-8?Q?=22Bj=C3=B6rn?= Bidar"'s message of "Wed, 09 Nov 2022 12:52:36 +0200") Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.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, RCVD_IN_DNSWL_NONE=-0.0001, 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:299418 Archived-At: 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 such= 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? >>> 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. >>> 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. >>> If the packages complete use case isn't meat it should at least get all >>> the features that it is useful without applying hacks so it can be used >>> in the next Emacs version. >>> I understand that you try to get it closer however that would then only >>> affect anything after Emacs 29. >> >> What hacks are you referring to? Is there a specific use-case you think >> must be added for package-vc to be satisfactory? > > First of all I Didn't know about these elpa-packages but there are two > cases where I think custom commands could be needed such as packages with= native modules or > some that require bootstrapping their build system by means such as > autotools. OK, but that is something that package.el doesn't handle either right now. This is a shared deficit, as I had mentioned in my message to Stefan just a few minutes ago. I would like to address it at some point, but probably not in time for Emacs 29. > Reunsing melpa package generation instructions just might not work as > good going by just using the package sources in place such as how borg > does it. I am still confused by your terminology. Package-vc has nothing to do with MELPA, we re-use the same package specifications that ELPA makes use of, e.g. https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/elpa-pac= kages.