From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: package-vc support for :files keyword Date: Fri, 22 Sep 2023 05:38:25 -0700 Message-ID: References: <87ttrshrib.fsf@hyperspace> <871qev6e53.fsf@posteo.net> <87r0mviltd.fsf@hyperspace> <871qevbhru.fsf@posteo.net> <87o7hzi82q.fsf@hyperspace> <874jjpvkst.fsf@bernoul.li> 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="19363"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Jonas Bernoulli , Tony Zorman , Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 22 14:39:04 2023 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 1qjfR1-0004rJ-VN for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Sep 2023 14:39:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjfQW-00034Y-W6; Fri, 22 Sep 2023 08:38:33 -0400 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 1qjfQU-00033P-Mn for emacs-devel@gnu.org; Fri, 22 Sep 2023 08:38:31 -0400 Original-Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qjfQT-0003WQ-44 for emacs-devel@gnu.org; Fri, 22 Sep 2023 08:38:30 -0400 Original-Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2b9338e4695so34824031fa.2 for ; Fri, 22 Sep 2023 05:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695386306; x=1695991106; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=PnoY9XotxtHzhbXys1drg212CHqF7cNVzN7vLzLOj+A=; b=KRYMPbOcmlKz56uhv+Up2rIfRX4PQBeWpo2P4HfxZCahz+URajPwx8zDttc7TazWY+ +S9hUYtxNWuU9CvX5BMA3heIOGX7ZJ7186UDjWSPFMcntCGdIxZh288+C+srcMbS0YvG MpXhXQoFvagLQ2zGIaMtPBZNgswtW5P7Zf/+3RyTBi/NhTQutyTa57p909+Q5MLjWIP7 7Zd/EFjCz/pgqfq5wtVKKtlj9wZ3075NHCudi/bL1cGfGIkHcjnaDfDrX1Sm6kYrwMES TU7+w7Of0kdC8nktgnFBT102gnUDo2cal5aW9blZzEcuIswRj0Buee7nNax9df8zcdxN rejg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695386306; x=1695991106; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=PnoY9XotxtHzhbXys1drg212CHqF7cNVzN7vLzLOj+A=; b=Jn2u8qE571nYu9+IZlE3t5y8tvfyLqALYlkEP+PS6q9Xu49p553QKVjoMG2iM8ZPJc IDAmdMgXlGw/0f7Ycd9L1WrTk6JszXprLw3WC2hewR7J5WZ8cnoqqGkl8Z5VBiY8pfR5 WQq0wM/2JmOTFxFL8nQNwGBClYF1u0nY55koQgOFWYlnQfvHCxy29ZlZNg3XDsq0fPGs 5IKSMLnnR9nJiAlELAndVn5vgFg0rG56E6ArEHIUoT2LWaNxx+nq3MEQH4t+3W51DAQz JUuMY9g9IXJ2FncG8P0NHpWzSX+4w7FY/L4pmgVNooghK0ixpglLdHZ/DKMmbyJGQGcG L5uA== X-Gm-Message-State: AOJu0Yw3sS/zKtbPSPKpo5513sH+JraBwKGgNMntqiTp3wikcSXj2o3M o4e7BmqTf5JOraBAFfqdQKfosO2LykA49QeARz8= X-Google-Smtp-Source: AGHT+IGUlMCOdiijVFdE2mmSB7NuADAmQIQhUI7pn0PPn3qQAXrZHY12sB9sRz7pTesOD9YzsXugMoNsUGNmKtwBOSI= X-Received: by 2002:a2e:8790:0:b0:2b1:ed29:7c47 with SMTP id n16-20020a2e8790000000b002b1ed297c47mr7558749lji.8.1695386306145; Fri, 22 Sep 2023 05:38:26 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 22 Sep 2023 05:38:25 -0700 In-Reply-To: <874jjpvkst.fsf@bernoul.li> Received-SPF: pass client-ip=2a00:1450:4864:20::22c; envelope-from=stefankangas@gmail.com; helo=mail-lj1-x22c.google.com 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, FREEMAIL_FROM=0.001, 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:310955 Archived-At: Jonas Bernoulli writes: > Tony Zorman writes: > >> This is not just for multiple packages in a single repository=E2=80=94at= least >> one has to somewhat broaden what "multiple packages" means. Some >> packages include small shims for bigger projects, and inadvertently >> require them as dependencies. The original issue[1] on the >> vc-use-package repo mentions org-ql[2], more specifically its helm >> integration in the form of helm-org-ql.el. Some people might not want to >> pull down helm as a dependency just for one file that they are not going >> to use anyways. >> >> I'm not sure how common of a situation this actually is, but at least >> for the big completion frameworks=E2=80=94helm and ivy=E2=80=94it's not = totally unheard >> of. If a user uses foo, and also bar, then foo may support bar optionally, or the other way around. We have ways of dealing with that without an explicit dependency, including e.g. autoloads and `eval-after-load'. The user will simply install both foo and bar, and things should ideally work as expected, including their integration. See for example use-package-ensure-system-package.el. Is there any reason why that can't work? A separate but related issue is that we should really teach package.el to deal with optional dependencies. I personally like Debian's model with "Recommends" and "Suggests" sections. > Here's a complete list for all of these packages that are available on > Melpa. Obviously not all of these pairings fall into the "foo and > helm-foo share a repository" category, but you can get an idea of what > other reasons exist for splitting a repository into multiple packages, > based on the names of the packages/libraries. I have included links to > the repositories, so you can quickly jump there, when only looking at > the names is not enough. Having reviewed this list, my conclusion remains that there is usually no need for splitting up packages like this.