From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ship Mints Newsgroups: gmane.emacs.bugs Subject: bug#72300: project.el: detect newly created project contained within another Date: Tue, 1 Oct 2024 16:20:05 -0400 Message-ID: References: <87r0bh8cy7.fsf@gmx.de> <86mslssny9.fsf@gnu.org> <04986428-27b5-462d-8f89-139cd56ea117@gutov.dev> <4ecab405-a03f-4dd7-af4b-f2d29b0420a4@gutov.dev> <6423009d-777f-453d-94e0-22c095b62d9a@gutov.dev> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b58ae50623700c24" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19424"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 72300@debbugs.gnu.org, Eli Zaretskii , Federico Tedin To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 01 22:22:17 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1svjNw-0004rX-FQ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Oct 2024 22:22:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1svjNj-00045h-Qq; Tue, 01 Oct 2024 16:22:03 -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 1svjNi-00045G-L0 for bug-gnu-emacs@gnu.org; Tue, 01 Oct 2024 16:22:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1svjNi-0006Qe-BF for bug-gnu-emacs@gnu.org; Tue, 01 Oct 2024 16:22:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:In-Reply-To:References:MIME-Version:To:Subject; bh=1g9SyoEpDHmzBnAkiAPr8NFjd66X+DsmApD7yGP4p9Y=; b=Nz+cwhIz0nvyLbfj7FedVgs11Z6yAnXOdFLqWDZLPCT5XEsc8U9ERNbfRKjnVEgB0LTQ+r6F1EOlWK/ojTPokgwgu+PFU4NtIqpfWzD0Ihl9VECDthNiEQ6bFrp7uh8+scWJDVhvBGeBUVPwtXOIRNxanhRLVrBrhu023AJ+fQ4C+QPkS0tHdfcMuVkw2Rt468qgpMV4gJCp4ccTZQWLmL/iZg/z7dsd0rqnpqXdE/CM5MHMrg7pLoCTyhertAZmr18CAToSPxHdPaewjqq5CoHBjn10vUS59MFaom3dAxx1Q/aTFd+CSuqVZXnKoYKmB9BRJv4iK9Hv1Od5vtwj8w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1svjNh-0000q3-OT for bug-gnu-emacs@gnu.org; Tue, 01 Oct 2024 16:22:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ship Mints Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Oct 2024 20:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72300 X-GNU-PR-Package: emacs Original-Received: via spool by 72300-submit@debbugs.gnu.org id=B72300.17278140862957 (code B ref 72300); Tue, 01 Oct 2024 20:22:01 +0000 Original-Received: (at 72300) by debbugs.gnu.org; 1 Oct 2024 20:21:26 +0000 Original-Received: from localhost ([127.0.0.1]:53443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svjN7-0000lP-9K for submit@debbugs.gnu.org; Tue, 01 Oct 2024 16:21:26 -0400 Original-Received: from mail-ua1-f54.google.com ([209.85.222.54]:51509) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svjN4-0000j9-8W for 72300@debbugs.gnu.org; Tue, 01 Oct 2024 16:21:23 -0400 Original-Received: by mail-ua1-f54.google.com with SMTP id a1e0cc1a2514c-84e8bb409b6so1924085241.3 for <72300@debbugs.gnu.org>; Tue, 01 Oct 2024 13:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727814017; x=1728418817; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1g9SyoEpDHmzBnAkiAPr8NFjd66X+DsmApD7yGP4p9Y=; b=fhDB1FhLZnWrcCpvx2vgBL1QO+l8T+dGRHzj/qWVm069MjIQj8uJ5phOWX4urHn1ai vtvJyevYEIGZTd8o4gKh/hgAv32mYpsF/E+TxlOBhLP2w4W9afUypD4VYlF22Vtbniv6 wmGGn7wttPylp4I/b7naXPeLMbVxWpu7NGULmEt9blXgLh4NJzXg6U+Lz4Z8MVFBax3o zCKQKrYlqX9t23CEra+lHPv5lCSb53yyvWqjTiU1PuNAceX79r178UKMDbZMbTfkiuAq 0VJhBWx7Zu/+iHVf7X8kkaG0uzIjWjnPWjZclgOVhQxFl6HUgvX1rRq3WseHFJbiM0qt xWRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727814017; x=1728418817; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1g9SyoEpDHmzBnAkiAPr8NFjd66X+DsmApD7yGP4p9Y=; b=pwocYFiF3NOVdtruyaRLyWxNlZNepWYoCCRu59N5fPc3cp0K5RUZirbb4aUA7/oDij lGvxrZR45bwEk1S6s5PnBPnmR5/IbG/9YHhXEyivgozCDSgsRImGjEP7CtTYWtudS9sN s1xz/u5U3eWe7vF0g/VH9Ll83+5H4d1zJNUTYsAfvye2lJ7G+YrgP6I0MK7nf2YHX9Z4 J9/R2XJ5UQpEpYKkjtpWB0oz8MJA5GnJYut53LJk06WiFDw4rcFfkQui2iYNW0kxTK8x ebYC/kPnFptZug1DYyO3ZBN/ugkZ8F1WGDuJVNzxt5+tifgyYa5NvJ4/NvLFI5jZWX1G vZQw== X-Forwarded-Encrypted: i=1; AJvYcCVI+kXjADui+W+sW7PcdbhmprcHA7/2u8w6Qk0ttQ8cnU/4RUS2bTBbYjNV0msGV0yrRrzVvg==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yxui1dH7ohtyA2Y316YcgrAmxMIlmgH9wE/DLcptFkZ1duGS6Cn euHczot7eA8BSrs44X4PUV43Inul7fhuEo0QdldK0jbNiEAkAGL30scXjDMpbGFmkTf5E8RhMVI Zaq0vueGWAZEiCqzQvWRRqltw7E4= X-Google-Smtp-Source: AGHT+IEmnKyjmsp0PZ/oXb0g5K2w5cYbmIqZ3fGAg1vSHdz4bMOCccW7uchropBQmoEzyr772ZICU6RADyqSy9dptlM= X-Received: by 2002:a05:6102:dcc:b0:493:de37:b3ef with SMTP id ada2fe7eead31-4a3e6855b10mr907842137.13.1727814016794; Tue, 01 Oct 2024 13:20:16 -0700 (PDT) In-Reply-To: <6423009d-777f-453d-94e0-22c095b62d9a@gutov.dev> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:292793 Archived-At: --000000000000b58ae50623700c24 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 30, 2024 at 7:10=E2=80=AFPM Dmitry Gutov wro= te: > On 30/09/2024 17:31, Ship Mints wrote: > > > Git attributes is a possible approach, with a downside of extra > process > > calls, which over Tramp (for example) would mean additional latency= . > > > > > > (defun project--value-in-dir (var dir)already incurs latency over tramp= , > > right? > > Yep, but almost every other separate I/O adds to it. So with other > things equal, I'd prefer solutions with fewer disk reads - at least for > the default behavior. > Indeed. It would likely have to be a shell-command-to-string via a tramp file name form. > > How about we just support filtering out submodules using the > > project-vc-ignores var? Which can be assigned in .dir-locals.el or > > through other means. > > > > > > Seems simple. Perhaps an abnormal hook so people can customize buffer > > local hook via dir locals? If they want to use git attributes, they > > could integrate that approach as an added/replacement function. The > > function list could default to a function that implements current > behavior. > > I'd like to say yes, but what would be a good place and name for that hoo= k? > > Note there is an existing hook called before-hack-local-variables-hook > which allows one to alter the applied local variables. But that one > might run more often than ideal - perhaps try it out and report back. > I'll dig back into project.el code and take a look when I have some focus to think this through. > Another approach might use a custom project backend which wraps the > existing project-vc - it would need to provide a custom implementation > for 'project-ignores' and could delegate the rest of the methods to the > parent. > Also possible. I wonder if this is what Spencer wound up doing to defray the cost of running "find" on a large hierarchy. > BTW, are you asking about using git attributes because there is an > existing workflow that somehow hooks into it, at some of your clients? > If not, then editing dir-locals.el to set the value of > project-vc-ignores directly seems like an easier approach. > I've used git attributes as semaphores for subdirectories in a monorepo to identify subprojects (which are not necessarily git submodules, but we have those, too). This helps with certain tooling external to Emacs. Sadly git-attr, it doesn't have a simple exit with 0 for success, non-zero for failure/missing attribute so needs a little parser for its results. The use cases for git attributes in a monorepo help segregate workflows among front end, back end, firmware subprojects, among others, where tooling is pretty different (and developer skill levels) and there are different workflows. I think I mentioned once before that there is no naming convention for custom git attributes that I'm aware of so I simply prefix ours with an underscore. So far, they're just semaphores where we look for check-attr output of "unspecified" vs. any value for a file/directory of interest. I haven't been that focused on this aspect in a while. I think there are some potentially tricky things to think through as I sense that project.el is becoming more closely tied to vc integration than mere project file association. In the past (I think on github), I talked about using a meta project to graft together disparate directory hierarchies for user convenience beyond just symlinks, though those work, when maintained. e.g., how does one find files that are conceptually common to a project that don't share a directory hierarchy root. The biggest example here is that user/admin/management documentation lives in cloud drives, while source code lives locally (via git, mostly). People work across those boundaries. There are meta project files in each disparate root, .project.meta files which all contain the same text to graft them together using tools we have. Some people put in symlinks (like me, I'm lazy) and that helps but not everyone shares the precise directory hierarchies across every machine making symlinks harder to deal with when checked into git (and there are Windows users). This may be a use case that project.el should never address, not sure. Only concrete, defensible and not-too-esoteric use cases matter, of course. -Stephane --000000000000b58ae50623700c24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Mon, Sep 30, 2024 at 7:10=E2=80=AFPM Dmitry Gutov <dmitry@gutov.dev> wrote:
O= n 30/09/2024 17:31, Ship Mints wrote:

>=C2=A0 =C2=A0 =C2=A0Git attributes is a possible approach, with a downs= ide of extra process
>=C2=A0 =C2=A0 =C2=A0calls, which over Tramp (for example) would mean ad= ditional latency.
>
>
> (defun project--value-in-dir (var dir)already incurs latency over tram= p,
> right?

Yep, but almost every other separate I/O adds to it. So with other
things equal, I'd prefer solutions with fewer disk reads - at least for=
the default behavior.
=C2=A0
Indeed. It would likely have = to be a shell-command-to-string via a tramp file name form.
=C2=A0
>=C2=A0 =C2=A0 =C2=A0How about we just support filtering out submodules = using the
>=C2=A0 =C2=A0 =C2=A0project-vc-ignores var? Which can be assigned in .d= ir-locals.el or
>=C2=A0 =C2=A0 =C2=A0through other means.
>
>
> Seems simple. Perhaps an abnormal hook so people can customize buffer =
> local hook via dir locals?=C2=A0If they want to use git attributes, th= ey
> could integrate that approach as an added/replacement function. The > function list could default to a function that implements current beha= vior.

I'd like to say yes, but what would be a good place and name for that h= ook?

Note there is an existing hook called before-hack-local-variables-hook
which allows one to alter the applied local variables. But that one
might run more often than ideal - perhaps try it out and report back.

I'll dig back into project.el code and take a look whe= n I have some focus to think this through.
=C2=A0
Another approach might use a custom project backend which wraps the
existing project-vc - it would need to provide a custom implementation
for 'project-ignores' and could delegate the rest of the methods to= the
parent.
=C2=A0
Also possible. I wonder if this is what Spe= ncer wound up doing to defray the cost of running "find" on a lar= ge hierarchy.
=C2=A0
BTW, are you asking about using git attributes because there is an
existing workflow that somehow hooks into it, at some of your clients?
If not, then editing dir-locals.el to set the value of
project-vc-ignores directly seems like an easier approach.
=

I've used git attributes as semaphores for subdirectories in a monorep= o to identify subprojects (which are not necessarily git submodules, but we= have those, too). This helps with certain tooling external to Emacs. Sadly= git-attr, it doesn't have a simple exit with 0 for success, non-zero f= or failure/missing attribute so needs a little parser for its results. The = use cases for git attributes in a monorepo help segregate workflows among f= ront end, back end, firmware subprojects, among others, where tooling is pr= etty different (and developer skill levels) and there are different workflo= ws. I think I mentioned once before that there is no naming convention for = custom git attributes that I'm aware of so I simply prefix ours with an= underscore. So far, they're just semaphores where we look for check-at= tr output of "unspecified" vs. any value for a file/directory of = interest.

I h= aven't been that focused on this aspect in a while. I think there are s= ome potentially tricky things to think through as I sense that project.el i= s becoming more closely tied to vc integration than mere project file assoc= iation. In the past (I think on github), I talked about using a meta projec= t to graft together disparate directory hierarchies for user convenience be= yond just symlinks, though those work, when maintained. e.g., how does one = find files that are conceptually common to a project that don't share a= directory hierarchy root. The biggest example here is that user/admin/mana= gement documentation lives in cloud drives, while source code lives locally= (via git, mostly). People work across those boundaries. There are meta pro= ject=C2=A0files in each disparate root, .project.meta files which all conta= in the same text to=C2=A0graft them together using tools we have. Some peop= le put in symlinks (like me, I'm lazy) and that helps but not everyone = shares the precise directory hierarchies across every machine making symlin= ks harder to deal with when checked into git (and there are Windows users).= This may be a use case that project.el should never address, not sure.

Only concrete, d= efensible and not-too-esoteric use cases matter, of course.

-Stephane
--000000000000b58ae50623700c24--