[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Eglot, project.el, and python virtual environments

From: Dmitry Gutov
Subject: Re: Eglot, project.el, and python virtual environments
Date: Wed, 23 Nov 2022 05:37:38 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 21/11/22 22:58, Augusto Stoffel wrote:
On Sun, 20 Nov 2022 at 17:36, Dmitry Gutov wrote:

If you want more food for thought, look up my previous messages in
this thread regarding "subprojects". And others' too.
How about the much simpler situation where you want a subdirectory of a
Git repo to count as its own project, completely disregarding any other

I guess it would be nice to support this by just creating a special
marker file, but I couldn't figure out if it's supported.

It's a seemingly simple issue which becomes hard once you want to create a turnkey solution for everybody which is simultaneously fast, easy to use and still flexible. Or at least for me it did.

There are a couple of patches I put up for discussion in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#82, but alas the discussion that arose went into some other direction.

In short, the issues are:

- Whether we need to be able to exclude the subprojects from project-files of the parent project. Can be useful with large projects; not so easy to do if the subprojects are defined by some file markers down in the directory tree.

- If we don't, I guess nobody needs the defcustom 'project-vc-merge-submodules' either?

- Or if we do, would it be okay to recommend the user customizes the ignores of the parent project manually to exclude the specific subprojects? In addition to setting up the markers. And this way we lose the potential ability to add their dirs to project-files of the parent, to make them more easy to reach (project-vc currently does that with project-vc-merge-submodules=nil), or list them through a separate command, etc.

- Would markers be limited to file names (perhaps with wilcards)? If so, it might be feasible after all to exclude marker-based subprojects if the user so wishes using an extra 'git ls-files -co -- ...' call. It's not free, though.

- Should subprojects obey "ignores" of the parent project? If they do (which would make sense in practice -- obeying .gitignore of the repo), how do we describe that semantically if a subproject is a separate project type/backend?

Anyway, I suggest you give the original messages a read (#82 and #83, at least) and let me know what you think. Preferably in the bug comments, since those will be easier to find later.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]