Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > It would be better to offer a way that you can install your own
>   > > patches _in the released version_, which is probably the version you
>   > > were using and wrote the patches for, and then preserve these patches
>   > > when you install new released versions.
>
>   > That is a long term goal, but if the foundation is to be merged before
>   > the next release, I have other issues that I'd like to address now and
>   > then return to this for Emacs 30.
>
> I'm not quite sure what that means -- what is the "foundation", and why
> is there a hurry to merge it in?

"Hurry" is the wrong way to look at it, I was just looking forward to
having a basic feature like this added to Emacs 29.  Of course this
shouldn't be rushed, but I believe the branch is currently in a
functional state that would be useful.

> But there is a general principle that it is better to get the external
> interfaces right before installing something new.  Changing those
> interfaces now won't require people to change habits; changing them
> later could do so.
>
> The code for checking out the current-version repo of an ELPA package
> should be very little different from the code for checking out the
> upstream repo.  If the latter is already working, getting the former
> to work equally well shouldn't take long.  Would you please do that?

It can be done, but I believe it would be best to add those kinds of
annotations to the server side (elpa-admin.el).  The issue is that
figuring out what version was used to release a package is non-trivial
using just vc.

> Once we support choosing between the two repos for a package, the name
> `package-vc-install' will be ambiguous -- it could fit either of those
> two cases.  It would not be a clear name to use.  So let's not define
> anything now with that name.

The reason I chose this name is because of the symmetry to
`package-install', and I still think this is nice.

> I suggest the names `package-repo' and `package-dev-repo' for checking
> out an ELPA package in these two ways, current repo and upstream/dev
> repo.  (I previously envisaged other names, but don't worry about
> those.)  Each of these names is clearer than `package-vc-install', and
> they will make the distinction (choice of repo) clear too.

In practice there is really no great difference between the "current
repo" and a "upstream/dev repo".

> I think `package-dev-repo' would be the command now called
> `package-vc-install'.

I am fine with renaming the file "package-vc" to "package-dev", but the
"-repo" suffix is not clear to me.  "-install" is clear in the sense
that it will fetch and activate the package, just like
"package-install", but "-repo" could do anything from opening the URL in
an external browser or printing some message in the echo area.