Don't link if the `-pkg.el` file is not found

[Fuco1]

I tried to link trinary devel version from my local git repo but it also installs the version from melpa

> eask link add trinary /home/matus/.emacs.d/projects/trinary-logic (1) :master
Running Eask in the development environment
Press Ctrl+C to cancel.

Executing script inside Emacs...

✓ Checking Emacs version 28.2... done!
✓ Checking system gnu/linux... done!
✓ Try constructing the package-descriptor (elsa.el)... succeeded!
Unmatched website URL ’https://github.com/emacs-elsa/Elsa’; add ;; URL: https://github.com/emacs-elsa/Elsa to package-file
Unmatched dependency ’cl-lib’; add (depends-on "cl-lib") to Eask-file or consider removing it
Unmatched dependency ’seq’; add (seq "VERSION") to package-file or consider removing it
✓ Loading Eask file in /home/matus/.emacs.d/projects/Elsa/Eask... done!

Package-file seems to be missing ‘trinary.el’
Installing 5 package dependencies...
Loading package information... done ✓
 - Installing dash (20221013.836)... done ✓
 - Skipping seq (2.23)... already installed ✗
 - Installing f (20230116.1032)... done ✓
 - Installing trinary (20230225.1944)... done ✓
 - Installing lsp-mode (20230227.1358)... done ✓
(Total of 4 dependencies installed, 1 skipped)

✓ Created link from /home/matus/.emacs.d/projects/trinary-logic to trinary-1.2.1

✓ You have now created the link, here are things you might want to consider:

 - [ ] ‘SOURCE-pkg.el‘ file Package descriptor
 - [ ] (Optional) ‘SOURCE-autoloads.el‘ Package autoloads
 - [ ] (Optional) Compile source package with ‘.elc‘ files Use ‘.elc‘ may be metter choice

If the source package uses Eask, you can use ‘eask‘ commands to accomplish these tasks.

 * ‘eask pkg-file‘
 * ‘eask autoloads‘
 * ‘eask compile‘

The resulting directory structure

[jcs090218]

It seems like you need a -pkg.el file in your trinary package, or else package.el would not recognize it as a package. Then you do eask install trinary it will show as skipped,

Loading package information... done
Installing 1 specified package...
 - Skipping trinary (1.2.1)... already installed

(Total of 0 package installed, 1 skipped)

You can generate it with eask pkg-file.

Output eask list --depth 0

Error loading autoloads: (file-missing Cannot open load file No such file or directory d:/_workspace/openai/.eask/29.0.60/elpa/trinary-1.2.1/trinary-autoloads)
 [+] tblui 20161007.1912 Define tabulated list UI easily
 [+] tablist 20200427.2205 Extended tabulated-list-mode
 [+] request 20230127.417 Compatible layer for URL request
 [+] magit-popup 20200719.1015 Define prefix-infix-suffix command combos
 [+] elsa 20230227.1727 Emacs Lisp Static Analyser
 [+] lsp-mode 20230227.1358 LSP mode
 [+] lv 20200507.1518 Other echo area
 [+] markdown-mode 20230227.342 Major mode for Markdown-formatted text
 [+] spinner 1.7.4 Add spinners and progress-bars to the mode-line for ongoing operations
 [+] ht 20230214.1632 The missing hash table library for Emacs
 [+] f 20230116.1032 Modern API for working with files and directories
 [+] s 20220902.1511 The long lost Emacs string manipulation library.
 [+] trinary 1.2.1 Trinary logic
 [+] dash 20221013.836 A modern list library for Emacs

(Total of 14 packages installed)

[Fuco1]

Ah I see now that it prints Package-file seems to be missing ‘trinary.el’. But I missed it in all the output. Maybe we should add some red cross or something so it stands out a bit more? Or actually, I think I would prefer the link command to just fail if it's not possible to link.

[jcs090218]

Yeah, the current behavior is from Cask. It might be easier if we just require a pkg.el file. The current logic is kinda complex,

cli/lisp/link/add.el

Lines 49 to 92 in dfac98b

	(let* ((names (eask-args))
	(name (nth 0 names))
	(path (nth 1 names))
	(source (expand-file-name path)))
	(cond
	;; Wrong arguments number.
	((<= 3 (length names))
	(eask-info "✗ This command only accepts maximum of 2 arguments: %s"
	(mapconcat #'identity names " ")))
	;; Source path not found!
	((not (file-directory-p source))
	(eask-info "✗ Can't create link %s to non-existing path: %s" name source))
	;; Create the link
	(t
	(let ((links (eask--links))
	(pkg-el (expand-file-name (package--description-file source) source))
	(pkg-eask (car (eask--all-files source)))
	(pkg-desc))
	(cond
	((ignore-errors (file-exists-p pkg-el))
	(with-temp-buffer
	(insert-file-contents pkg-el)
	(setq pkg-desc (ignore-errors
	(if pkg-el
	(package--read-pkg-desc 'dir)
	(package-buffer-info)))))
	(setq eask--link-package-name (package-desc-name pkg-desc)
	eask--link-package-version (package-version-join
	(package-desc-version pkg-desc)))
	;; XXX: Install dependencies for linked package
	(eask--install-packages (eask--package-desc-reqs pkg-desc)))
	((ignore-errors (file-exists-p pkg-eask))
	(let ((deps))
	(eask--save-load-eask-file pkg-eask
	(progn
	(setq eask--link-package-name (eask-package-name)
	eask--link-package-version (eask-package-version))
	(setq deps eask-depends-on))
	(eask-error "✗ Error loading Eask-file: %s" pkg-eask))
	;; XXX: Install dependencies for linked package
	(eask-install-dependencies)))
	(t
	(eask-error "✗ Link source %s doesn't have an Eask or %s-pkg.el file"
	source name)))

[jcs090218]

I've opened a PR in #133. Can you try this branch?

[Fuco1]

I tried linking another package (ansi.el) and it works better now indeed. It's much less confusing.

But actually, assuming the other project is using Eask as well, maybe we could generate the package file there automatically?

[jcs090218]

But actually, assuming the other project is using Eask as well, maybe we could generate the package file there automatically?

That's was my first thought, but I don't know generating files somewhere else (consider link outside of the project) provides the best UX. Two things I am considering:

1. Best UX
2. Generating outside of project may cause confusion? 🤔
3. Maybe we can create a custom variable so users can customize in the Eask-file?

I may just think too much. 😅

[Fuco1]

Actually yea, you're right about point 2.

I would then just change the wording on this

Options are,

 - [ ] Use ‘eask pkg-file‘ to create one
 - [ ] Write your own ‘-pkg.el‘ file

to emphasize more that you need to run eask pkg-file in the other (linked) project.

[jcs090218]

I've implemented the behavior in #139. I think not enough people use Eask + link, so I've added to see what people think. Let me know if we should revert this. ;)

to emphasize more that you need to run eask pkg-file in the other (linked) project.

Would you like to open a PR for this? 😁Like this?

- Options are,
+ Options are, (in linked project)

 - [ ] Use ‘eask pkg-file‘ to create one
 - [ ] Write your own ‘-pkg.el‘ file

[joshbax189]

to see what people think

I think the name param should be removed from eask link:

• package.el checks the define-package form in -pkg.el for the name, not the folder/link in the elpa directory
• -pkg.el or Easkfile are required by eask link
• when only the Easkfile is present, a -pkg.el is generated using eask generate pkg-el
• eask generate pkg-el does not allow changing the name within -pkg.el

So <name> is always ignored, except for naming the symlink, which is never visible to the user (using eask emacs).

<name> is also not useful as an alias for the folder because it is expanded to name-version and that form is required for eask link delete. For example

eask link add foo ./foo
eask link delete foo # fails
eask link delete foo-1.0.0

Even if it did work as above, then there would be three ways of referring to the linked package: by package name, by link name/alias, and by directory name... confusing!

---

IMO eask link <dir> should behave as though the user ran package-install on dir, but using a symlink rather than copying dir so that the source files are always up to date.

Put another way, after running eask link ./foo:

• package foo should be available when running eask emacs
• changes in ./foo/foo.el should apply next time I run eask emacs

This means there must be a -pkg.el and autoloads (in the info manual for package.el it expects that every package defines some autoloads, so there must always be an autoloads file). And emacs itself may create .elc files in the linked dir. This is probably why package-install-file copies the file into a new directory within elpa/...

In terms of UX it might be better to require that the linked dir has an Eask file already, then the user can generate or clean the messy files. Or perhaps to remove the link command entirely and instead use install dir as a less messy alternative? That would match the behavior of package-install-file too.

---

Summary
My two suggestions, either:

• eask link add <name> <dir> should be replaced with eask link add <dir>
  and eask link delete <name> with eask link delete <package-or-dir>
  User is expected to accept .elc, autoloads and -pkg.el appearing in dir and to recreate them when necessary
• Or, deprecate eask link replace with eask install ./dir
  User runs eask install again after changes to dir, so autoloads and .elc are all fresh

[jcs090218]

We can implement both since all these commands have their own usage. eask install <dir> performs clean installation, and eask link is more flexible and should be used more often throughout the development.

I originally had this idea but didn't know how to differentiate between eask install <dir> and eask install <package-names> since there is a tiny chance that the names are the same. 🤔

I think the name param should be removed from eask link:

IIRC, the parameter name is for compatibility with Cask’s link command; see https://cask.readthedocs.io/en/latest/guide/usage.html. But I agree with you since it was confusing when I first implemented it. 🤔

@rejeep, Can you explain the intention of the name parameter in the link command? I would greatly appreciate it if you could reply! Thanks!

[joshbax189]

Looks like Cask's link was originally a copy of npm link:

• cask/cask@80517f0#diff-8feb0391f6652d58c375809a707e454fa7f494630e162827ee585a2085c7fa16R230

So usage would be like:

# in ./foo
eask link # adds package "foo" to local archive
# in ./my-package
eask link add foo # looks in local archive and installs foo

The latest version (likely the one you matched for compatibility) seems to use name as an alias so you can link delete without typing the full path.

eask link is more flexible and should be used more often throughout the development.

The problem is eask link fails (or the linked package fails to load) unless all of the install steps are carried out in the linked directory:

• missing -pkg.el: can't load the package
• missing autoloads: can't load the package
• stale .elc files: possibly buggy behavior
• package dependencies not installed: can't load package

these commands have their own usage

From looking through issues here and on Cask, I've found these use cases:

• override a dependency with a local version (no change to Easkfile)
• use a local package as a proper dependency (saved in Easkfile)
• have a local "archive" of packages installable/linkable by Eask (original definition of cask link)

Do you have any others?