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: Adding the `prescient` packages to NonGNU ELPA? Date: Sun, 20 Nov 2022 15:41:12 +0000 Message-ID: <87wn7pljl3.fsf@posteo.net> References: <16193c73-ab80-04c9-558f-d5e6142f38f3@protonmail.com> <871qpydllo.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="37550"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Kangas , Okamsn , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 20 16:41:45 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 1owmS1-0009cU-L9 for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Nov 2022 16:41:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1owmRc-0006PG-Mc; Sun, 20 Nov 2022 10:41:20 -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 1owmRa-0006P7-HF for emacs-devel@gnu.org; Sun, 20 Nov 2022 10:41:18 -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 1owmRX-0000v6-SF for emacs-devel@gnu.org; Sun, 20 Nov 2022 10:41:18 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 67524240028 for ; Sun, 20 Nov 2022 16:41:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1668958873; bh=269fU2WptP4UiU4jfTRbABoPntmWQp3sIVABjSZmZQI=; h=From:To:Cc:Subject:Date:From; b=dkffFWkR9zLR2jDJIlSctBBDtkUTtcaCfAQc9nRh/rrViAa+e7fwBdQUPqPh4+/H8 fx/LXNPVqrP4jXGUvNiCwHxKBTKzqO+jmxE0uJCf8DP+zST8GWWFKx2l7H2BgU14sD iEnUWfNVqjwin+KfoYUgwzlBZ279Vxt0i5uWKY6sgi+K1RNJ6TFZC7Y/QWwyfbFa1Z Mr5zy3mUQh3ZvFvmYHD8TadIitzqbcZ+iFR6eiaTHv+ORJRWQ21OPvUWFkRHeQ3JjS hT2UqCMioWyeOXaCRhwktitEKmhxn/Ho9MNTshdRbplwnGR7crM7zXLvWTBmMkFAVJ Wt1dq29ZBl20Q== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NFZVw2ls3z6tmr; Sun, 20 Nov 2022 16:41:12 +0100 (CET) In-Reply-To: (Stefan Monnier's message of "Sun, 20 Nov 2022 10:19:41 -0500") 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=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:300253 Archived-At: Stefan Monnier writes: > Stefan Kangas [2022-11-20 03:23:09] wrote: >> Philip Kaludercic writes: >>>> All of these packages live in the same repository in the link below. >>> >>> Would it be possible to change this? E.g. by making each project live >>> on it's own branch. That would make the :ignored-files rules below a >>> lot simpler. >> >> We could also make the rules simpler by adding support for the inverse >> of :ignored-packages. > > Multi-package repositories are fundamentally incompatible with > `package-vc` (they kind of work, but with various caveats). They will have the same issues as elpa-admin has, right? In that case, the issue will be if someone just wants to install prescient, they will have all the other dependencies unconditionally "installed" along with the rest. At the same time, if someone installs one of the more specialised packages, which adds the same repository as a dependency, you'll have the same package checked out twice, and I would have to guess which takes priority in `load-path'... > So I think we definitely don't want to support them better, but instead > we should discourage them. If we want to invest efforts in that > direction it should be efforts to make it easier to "re-merge" packages > so as to move away from the problem. Agreed.