Is relative path handling of buttercup-discover-run correct?

[codygman]

For my system at least I work around this with:

(let* ((default-directory "~/hci/test")
       ;; hack to ensure that relative filepath handling of buttercup doesn't mess up our expectations
       (command-line-args-left '("~/hci/test"))
       ) (buttercup-run-discover))

This patch also works in buttercup-discover-run:

@@ -32,7 +32,7 @@
       (dolist (file (directory-files-recursively
                      dir "\\`test-.*\\.el\\'\\|-tests?\\.el\\'"))
         (when (not (string-match "\\(^\\|/\\)\\." (file-relative-name file)))
-          (load file nil t))))
+          (load (expand-file-name file) nil t))))
     (when patterns
       (buttercup--mark-skipped buttercup-suites patterns))
     (buttercup-run)))

I don't know that this is useful in the general case, but it would be nice as well to catch the load error and rethrow the messae with a full path. It would have saved me 30 minutes debugging something in one directory when for some reason this was run in an entirely different place on my system.

From:

Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such file or directory" "foo")

To:

Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such file or directory" "/full/path/to/foo")

[snogge]

I'm sorry, I don't understand what problem you are describing.

Could you expand a bit on what the file structure looks like, what
command you are running, and in what directory?

What happened that you did not expect?

[codygman]

I'll have to take some time to break this down into something more useful, but it's not high on my priority list since I've worked around it and it seems I'm the only one who's encountered an issue with this.

I noticed the quick response, thanks for that. Sorry I couldn't respond at the time.