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: Reconsider defaults for use-package-vc-prefer-newest Date: Fri, 20 Sep 2024 20:34:11 +0000 Message-ID: <87setum5do.fsf@posteo.net> References: <87wmj7dftf.fsf@posteo.net> <87setvxyt6.fsf@gmail.com> <87jzf7o13b.fsf@posteo.net> <87msk3jr0u.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34187"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Martin =?utf-8?Q?Edstr=C3=B6m?= , "emacs-devel" , Tony Zorman To: Suhail Singh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 20 22:35:09 2024 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 1srkLM-0008ju-NR for ged-emacs-devel@m.gmane-mx.org; Fri, 20 Sep 2024 22:35:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1srkKb-0005ml-Q8; Fri, 20 Sep 2024 16:34:21 -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 1srkKa-0005mO-23 for emacs-devel@gnu.org; Fri, 20 Sep 2024 16:34:20 -0400 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 1srkKX-0004sT-2z for emacs-devel@gnu.org; Fri, 20 Sep 2024 16:34:19 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 7AD3C240027 for ; Fri, 20 Sep 2024 22:34:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1726864453; bh=xAi6E/VYDlftCxzHKY9+B0ZAneCyynmLKpGN2k6Jue4=; h=From:To:Cc:Subject:Autocrypt:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=NN2vTPJOFZj3RauMg4zQeQL3FWAbqDImGk5+ZWd9kni+ju4SwqyL08dvto9RfnviQ N7SqAxkws5xJ/L4JG0H6saedOfAsZkee52uo/1Vl8OfrAnFZecOPWwEi0CNM+SAQ7Y kXIhcIPWhHHSSISh0JK557e7RzpxNOhm5NnD6O04x6KMzsocTCHWWSNPoHNQw5xQOG W2gDGe6K/XVvgavo20Q4uNzIJFsm5aUTYtq5buJMVF7HDGyrCm/x5ix+C6vTh5bBBM jWPICdQkK4AKv+pACHhkkSqmvBkWbTypoALWgD9G97C9DWKE3NBeIlWkVRAErzuYvX iN8vYdiojvgTQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4X9PHm4Q6Qz9rxB; Fri, 20 Sep 2024 22:34:12 +0200 (CEST) In-Reply-To: <87msk3jr0u.fsf@gmail.com> (Suhail Singh's message of "Thu, 19 Sep 2024 17:02:41 -0400") Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM OpenPGP: id=philipk@posteo.net; url="https://keys.openpgp.org/vks/v1/by-email/philipk@posteo.net"; preference=signencrypt Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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:323867 Archived-At: Suhail Singh writes: > Philip Kaludercic writes: > >>> Would it be possible to reflect the commit corresponding to the version >>> in the "Other versions:" field in the output of M-x describe-package ? >> >> Why under "Other version:" (which links to other packages). > > For a package that is available under both MELPA Stable and NonGNU ELPA > one can encounter the situation where the versions look the same, but > instead point to different commits. They don't necessarily have to > point to different commits, and in fact when they do I would consider it > a bug. However, as of today, a user only becomes aware of this if they > follow the links in the "Other version" and then contrast the "Commit" > information in the subsequent package's description with the one from > the prior page. > > An example of a package where this was observed in the wild (probably > not the only case) was julia-mode. The 0.4 version of that package on > NonGNU corresponds to commit 6408b96c1c97e41bc2af060d661afee4f7b22e89 > whereas the version 0.4 on MELPA Stable corresponds to commit > 8bfc709716a257521cb386f20b8932e83db930a9 . > > Since the information is available via M-x button-describe on the links > to the other packages, hopefully it could be made visible (perhaps via > some customization). One concern I have would be that an entire revision string can get very cluttered, and is usually not interesting (as I don't use third-party archives, I don't have duplicates of the kind that you describe). I wonder if indicating a "commit mismatch" for remote packages might be interesting (we explicitly don't want this for local packages, e.g. packages installed via package-vc). Could you perhaps elaborate on why you consider this to be a bug? >> IIRC the commit of a VC package should appear under the commit header. > > That necessitates additional clicks. If those clicks or button pushes > could be avoided it would improve user convenience. True, but there are many things that could be made more convenient that only interest few people. I am trying to understand why this is something that would interest everyone. >> There is the possibility of using a symbolic name if available. > > Could you please give an example? What I had in mind was using `vc-git-symbolic-commit'. So in the case of Git: If the commit is following the "master" branch, then it would print "master" instead a commit hash, likewise if the package is checked out on some tag, it could display that. >>> Additionally, if it were possible to reflect the commit date as well, >>> that would be helpful as well. >> >> I don't think there is a nice vc-generic way to extract the date of a >> commit, at least without extending the vc interface any further. I >> might be mistaken though. > > I may be mistaken, but my understanding was that if `annotate-command' > is defined for a backend then this may be possible via `annotate-time'. >From what I see, that would only give us "the time of the next line of annotation at or after point, as a floating point fractional number of days.", and not something we can cleanly use to get an exact date. I mean you could try to multiply it with (* 60 60 24) to get the value that was probably passed to `vc-annotate-convert-time', but that feels unreliable to me. But I too might be mistaken. >> The other issues is that if you only have the revision string from the >> ELPA server, without any checkout, it isn't easy/cheap to determine the >> date even if you just wanted to support Git. > > Ah. That is, indeed, a problem. Out of curiosity, what is an example > of such a revision string (say, for the julia-mode package from NonGNU > ELPA)? In the case of Git it is just a commit hash, like the ones you gave above? -- Philip Kaludercic on siskin