emacs-devel
[Top][All Lists]
Advanced

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

Re: [package-vc] Consider cleaning up files from install process


From: Adam Porter
Subject: Re: [package-vc] Consider cleaning up files from install process
Date: Tue, 19 Sep 2023 09:34:03 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1

On 9/19/23 08:50, Philip Kaludercic wrote:

An alternative would be to follow Quelpa's example: rather than
loading the package directly from the git repository's directory, the
package's files could be copied into a new directory in the elpa/
directory, and Emacs could load the package from there.

As a developer, I would prefer that approach, because I don't usually
want Emacs to load whatever commit I may have checked out in a
package's repository.  I want to install a commit of a package into my
Emacs configuration and have that one loaded until I install a
different one.

Isn't this workflow already supported by `package-install-file'?  And
otherwise, there wouldn't be much of a point to just replicate the
functionality of an existing package manager.

That doesn't seem to do the same thing: it doesn't install from a git repo, per se, but from local files or directories:

  (package-install-file FILE)

  Install a package from FILE.
  The file can either be a tar file, an Emacs Lisp file, or a
  directory.

What I like to do is to install the package from the git repo as a, well, "normal package," i.e. as if it were installed from ELPA. That's how Quelpa works: it produces, e.g. "~/.emacs.d/elpa/PACKAGE-VERSION/PACKAGE{,...}.el". I don't have to have a local clone of the repo first.

(Also, the name of the command suggests that it only installs from files rather than directories; I didn't even realize it could install from directories until now.)

In other words, the way package-vc-install currently works leaves me
vulnerable to this scenario:

1.  I use package-vc-install to install one of my packages from its
local repository directory.
2.  I check out a feature branch of that package to work on a new
feature, saving some files but not loading any of the changed code.
3.  I restart Emacs (e.g. maybe I shut down the system and turned it
back on the next day).
4.  That work-in-progress feature branch of my package gets loaded
into Emacs automatically (which may be entirely broken, being a WIP).

I understand your issue, but anecdotally, I can also give an example
where I wanted to change some functionality, by M-x find-function'ing
the source buffer and then loosing the change after upgrading the
package.

IMHO that seems like a sort of user-error, to leave uncommitted changes in a repo that's under the control of a system that doesn't take such changes into account when operating on the repo. IOW, if I install a package with command package-FOO, I expect the files it makes to be under its purview, not mine; they are not my personal data files, but belong to Emacs and its package.el library, the same as if I used "M-x package-install".

To put it another way, it seems like a bit of an anti-pattern to develop a package that's stored in "~/.emacs.d/elpa"--that directory is supposed to be for installed packages' files, and it should be safe to wipe that directory out at any time and reinstall packages from their sources--after all, "M-x package-delete" shouldn't be wiping out user data. Development on packages should be done on clones stored outside of "~/.emacs.d", e.g. in "~/src" or whatever one uses. IMHO, of course--Emacs is all about user freedom--yet I think we should encourage the better practices.

Whereas if I use Quelpa, it installs the files a package's recipe
specifies into the expected location in the elpa/ directory, and that
remains independent of whatever I may have checked out in the
package's local git directory.  My Emacs configuration and installed
packages remain consistent regardless of whatever in-between state I
may have left a package's repository in.

Philip, would you be willing to consider switching to that model for
package-vc-install, or offering it as an option?

Can you describe the interface you are imagining.  From what I
understand, it should be possible to reproduce what you need by
combining `package-vc-checkout' and `package-install-file'?

Well, I would expect it to act similarly to Quelpa:

1. Clone the git repo (shallowly, at least by default) to a directory (perhaps a temporary one, but at least one stored in the appropriate XDG cache directory, outside of user-emacs-directory).

2.  Call package-install-file on that worktree.

3. The package ends up installed into package-user-dir as if it were installed with package-install from ELPA.

Then if the user wants to modify the package, he should either a) use a local clone wherever he keeps such projects, or b) configure package-vc to clone the repo to such a directory, and then a command could automate finding the source files in that directory rather than the ones in package-user-dir which are loaded into Emacs. (IIRC Straight, for example, does something like this, but I don't use it myself.)

Do these explanations clarify what I mean? Let me know if I need to try again. :)

--Adam



reply via email to

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