From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.devel Subject: Re: [elpa] main 8f4cb59: * elpa-packages (counsel, ivy, swiper): Auto-sync. Date: Thu, 11 Mar 2021 17:12:18 +0000 Message-ID: <87im5x8vil.fsf@tcd.ie> References: <20210225102521.11653.64611@vcs0.savannah.gnu.org> <20210225102523.7CEF420B28@vcs0.savannah.gnu.org> <87h7m0z07r.fsf@tcd.ie> <87mtvsundg.fsf@tcd.ie> <875z20m0oa.fsf@tcd.ie> <87eegn18rr.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9489"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org, Oleh Krehel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 11 18:18:38 2021 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 1lKOxK-0002Nj-P6 for ged-emacs-devel@m.gmane-mx.org; Thu, 11 Mar 2021 18:18:38 +0100 Original-Received: from localhost ([::1]:35334 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lKOxJ-0005bZ-MD for ged-emacs-devel@m.gmane-mx.org; Thu, 11 Mar 2021 12:18:37 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60512) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lKOrM-00009R-Hl for emacs-devel@gnu.org; Thu, 11 Mar 2021 12:12:30 -0500 Original-Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]:42670) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lKOrH-0006BF-So for emacs-devel@gnu.org; Thu, 11 Mar 2021 12:12:27 -0500 Original-Received: by mail-wm1-x329.google.com with SMTP id b2-20020a7bc2420000b029010be1081172so13313552wmj.1 for ; Thu, 11 Mar 2021 09:12:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd.ie; s=google21; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=nyNmqNg3AUe77EY+/Ifo7DwnvLGZnJ8VJ4wGZVWD9qg=; b=JmsdVvtg/TWv8oV0zJDnTPEnlwX2JyzzQdmgQL6tV9M6pj1/f02TGWOvkZw5BTjl/C c1RM4EaqZ+f6a4ktkyWUU6vCivGCg7zxoHK2vljrW9wn3jO/Qgj3GvOI+FFek2slDGSx CAKyuiH8y0URxr2M1/3l21GA/mFDs6FbXIbTD/+zRYjoOqyuaxTlVEGuaaChG8ud4OqZ OWJhMFj2Wk6Y0YqFQrn644bcwmKJiA0vB+1zG+ocKNgjfEU/YXVldt68P80RPvRr8bVX tZ8QidW06LhL/d78briyX8UZk0qHmGODRmp7ntyIaCih1Q12qZAgX4UFBDuZDXqIiIQH yCOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=nyNmqNg3AUe77EY+/Ifo7DwnvLGZnJ8VJ4wGZVWD9qg=; b=s4ybzDhsLC3OOz8Y2kv6N7zYpwOMDyQZyKAC+GaPfZLcX3v3/e/+X37gGqlUV2RoFH XWTDSbcedeDI0zKQ5CZ0xNeLN6FUu9VQAthEi1Zoj6wuoQ8vPgPTlgDO4CApvBKuw1Ru Nu3nkAFNmeSb5HWnlIWMDxeadm7A0AaZ0vb2JcRfQGoUs0SGjM3L57+QAe+Y67Gg5Qvo VpBdwTUNrZhPI65B+tYRtKvGptFZPx9enwr3EbsZWylw1x1NH/yNsimyjS+rucBDbCr/ 1c8spW+4Oa/AjTV1DUabXKjaq5O5p6rArkw0xcVv+x/VMRayfk1HWL78OGxY1ZsPqQxf dP1w== X-Gm-Message-State: AOAM531moAukLFCCcdO49KpTznKONafj4iEtEpxkDnATD1uA/uQB5Tna PnFIMbG+bzjKYr0MoRqtuWvB1Q== X-Google-Smtp-Source: ABdhPJyb17eNJ2K/k0YaoQIBpSR4gIlSdXkal52pXvGmwJhmRCimcwRzO0QYXf42z4mr34BHGkSjng== X-Received: by 2002:a7b:c842:: with SMTP id c2mr9300472wml.100.1615482740109; Thu, 11 Mar 2021 09:12:20 -0800 (PST) Original-Received: from localhost ([2a02:8084:20e2:c380:d15:339e:aa10:60f1]) by smtp.gmail.com with ESMTPSA id s16sm4766851wru.91.2021.03.11.09.12.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Mar 2021 09:12:19 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Thu, 11 Mar 2021 10:48:26 -0500") Received-SPF: pass client-ip=2a00:1450:4864:20::329; envelope-from=contovob@tcd.ie; helo=mail-wm1-x329.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, 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.23 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" Xref: news.gmane.io gmane.emacs.devel:266337 Archived-At: Stefan Monnier writes: >>> - as discussed earlier, we could have each subpackage have the complete >>> upstream Git and only create the subpackages via `elpa-package` >>> filtering out the other files. >> That would be nice to have in general, but it doesn't solve the >> inefficiency when multiple packages are bundled from the same repo. > I don't understand the "when ..." qualification, since my suggestion is > only meaningful in that precise case. As for the inefficiency: as long > as the upstream is not enormous and that we don't have too many packages > following that model, it's bearable. If that's acceptable (albeit discouraged), then that could work, yes. >>> - if there's really only one version number shared by all the >>> sub-packages, I'd tend to argue that maybe there should only be one >>> package ;-) >> I tend to agree ;). Not my call to make, though, and that ship is >> either getting smaller or sailing away. >>> - split the upstream repository. >> Not my call to make. > > Of course it can also be a mix of the two and it can be done in bits and > pieces: every bit helps. So maybe we can start by lobbying the upstream > for one specific subpackage we identified as being a good candidate for > either a separate upstream repository or for having the subpackage be > merged with another. Consider this the lobby, then :). (Oleh is already CCed.) Just today I had to bump only ivy-hydra's version, because it was unnecessarily requiring a newer version of hydra that hasn't yet been pushed to elpa.git. The packages ivy-avy and ivy-hydra are considered optional integrations with the separate packages avy and hydra, respectively, so they seem like the best candidates for splitting into separate packages (or merging with the avy and hydra packages, I think). ivy, swiper, and counsel are too coupled to split, I think. So my vote is for either distributing ivy, swiper, counsel, ivy-avy, and ivy-hydra as a single superpackage that mirrors swiper.git development, or splitting ivy-avy and ivy-hydra out of swiper.git. >> I guess another alternative to :version-map would be Git tags? >> E.g. using an N.N.N-elpa scheme or something like that. > > Fetching tags from upstream is problematic (because we have a single > elpa.git repository for all packages), but we could use tags manually > pushed to elpa.git, yes. I was thinking of the latter indeed, as a more "Git-native" way of pointing to a release. I can't promise to implement any of these features for another few months though (at least not without a guilty conscience ;). Thanks, -- Basil