`crafted-init-config` automatically finding directory possibly confounded by submodule use

[Remillard]

`crafted-init-config` automatically finding directory possibly confounded by submodule use

[Remillard]

May have been a Windows issue then, or combined Windows+git issue. I'm pretty sure it wasn't exactly a "me" issue as at the point where I call that, I've done:

1. Crafted Emacs early-init.el
2. Snippet of code to load custom.el
3. Set temporary file directory variable.
4. (load ~/.emacs.d/crafted-emacs/modules/crafted-init-config")

Then following that, a little blurp about setting up use-package then I call my first (require 'crafted-xxx-package) line. None of these things are elaborate enough to make me think it was my situation where crafted-init-config couldn't automatically set the crafted-emacs-home variable. (So for now, step 3.5 is setting that variable, then running crafted-init-config and everything loads just fine, so that's the only issue I'm aware of.

[jvdydev]

So, it turns out, vc-find-root even works when there is not .git or .github directory (as if > you had just downloaded the project source).

That's interesting, then again it was the alternative version in our code (when there was no git), so clearly someone knew that in the past.

May have been a Windows issue then, or combined Windows+git issue.

Well, the current iteration of the code does seem to break on Linux too (from my testing) if in a submodule (or crafted-emacs not being the root of the git-tree) and git is found in PATH.

I think moving forward, this section of code needs a little more checking that we're doing the right thing and otherwise actively signaling to the users that there is something they need to do manually (for one reason or another).

[jeffbowman]

Thanks!

Will need to look into how we might detect submodules in scenarios like this. Probably need to update the documentation with hints about setting the crafted-emacs-home value before loading crafted-init-config in scenarios like this.

[Remillard]

Is relying on git necessary here? Is there a way for the routines in crafted-init-config.el to know where the file exists? If you're using git for identifying the project head, there's no real reason to believe that the user has modified the repository tree. Could possibly derive the project root from the location of the initial file.

Otherwise, certainly works to set the directory and I'm glad that it was written to check for this variable and use it when set. Solved my problem completely. It was just the automatic method that didn't seem to work. Anyway, hope the report helps.

[jvdydev]

ye, the current code in question is:

;; crafted-init-config.el (line 69ff)
(when (null crafted-emacs-home)
  (setq crafted-emacs-home
        (expand-file-name
         (if (executable-find "git")
             (project-root
              (project-current nil (file-name-directory load-file-name)))
           (vc-find-root load-file-name "modules")))))

As there is already a fallback (vc-find-root) to using git, I wonder if there really is a need to use project-root with git here.

Something like this should get the same result:

(when (null crafted-emacs-home)
  (setq crafted-emacs-home (expand-file-name (vc-find-root load-file-name "modules"))))

Alternatively, we could check if the project-root path contains a modules directory, but that feels a bit excessive.

[jeffbowman]

Something like this should get the same result:

(when (null crafted-emacs-home)
  (setq crafted-emacs-home (expand-file-name (vc-find-root load-file-name "modules"))))

I was, quite literally, just testing this. I think I originally used project-root as it provided what I needed, and I use projects, and checking this code out from git would give the expected result. However, if the project is downloaded but not checked out using git, then what? That particular piece still needs some re-evaluation. But for git submodules, which this issue is about, the vc-find-root is sufficient as well as in cases where the project was cloned to it's own directory.

[jvdydev]

For the other case, we could go the (potentially fragile) route of going of "path relative to currently executing file" route.
Otherwise, I'd propose a good error message explaining that it cannot locate the crafted-emacs installation and ask the user to set the crafted-emacs-home variable manually.

[jeffbowman]

So, it turns out, vc-find-root even works when there is not .git or .github directory (as if you had just downloaded the project source).

I'd propose a good error message explaining that it cannot locate the crafted-emacs installation and ask the user to set the crafted-emacs-home variable manually.

Maybe we check to make sure crafted-emacs-home is set before setting the load-path and if not throw an error with a message that it needs to be explicitly set by the user. Something along the lines of:

(unless crafted-emacs-home (error "Please set the crafted-emacs-home prior to loading the crafted-init-config module."))

[sthesing]

Closing this, because it's addressed by #391.
Thanks to everyone involved.
@Remillard feel free to reopen if necessary.