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. ]]]
>
>   > > If the main purpose of this feature is for people to test, debug and
>   > > develop the development version, I think it is wiser not to speak
>   > > of "installing" from VCS.
>
>   > Not necessarily, another advantage might include the ability to maintain
>   > personal changes that don't get overridden by updates.
>
> That would be a useful feature.  But I think it would be unfortunate
> (and not what users want) to tell them, "To make and save your own
> patches, switch to the development version of the package."
>
> 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.

>   > In general I would like to see something like "package-vc" being
>   > regarded as a means to make software freedom more practical/perceptible.
>
> That is a good general goal, but I don't think it applies to this
> question.  Whether you want to try a development version is one
> question; whether you want to make patches (and desire to preserve
> them across updates) is another question.  Let's make the latter feature
> available for the reeased package also.
>
> I understand that may be some extra work.  However, merging your local
> patches with upgrades is not always going to be trivial and
> trouble-free.  Often there will be no conflict, but sometimes there
> will be one.  One way or another, you will need to be prepared for
> that if you start preserving your patches across upgrades
>
>   > > Presenting the feature as a way to "install" would encourage people
>   > > who are not really thinking of testing, debugging or developping the
>   > > package, and motivated only by a vague wish for "the latest thing."
>
>   > I agree that people might think of this idea, but then again what is the
>   > issue if they do?
>
> They are likely to get different behavior, and more bugs.
> There is a good reason for making releases: in general, that makes
> things more reliable for users.  That applies to packages as well
> as to Emacs overall.  Running the development sources of anything
> carries greater risks.  Some users want to take those risks, but
> it would be a mistake to urge all users to do that.

I agree in principle, but with two caveats.  Consider that most people
use package archives like MELPA, that distribute the most recent commit
by default, so this is not unfamiliar to many users.  The second point
is that due to the usage of version control, the user is able to revert
to a previous commit or even use their own branch where they pick and
choose the commits they are not interested in.

>   > I proposed a library along those lines last year that would automate
>   > this (it was called "site-lisp.el" in case you want to look the
>   > discussion up).  It automatically byte-compiles, prepares autoloads and
>   > adds the directory to the load path for all files/directories in
>   > ~/.config/emacs/site-lisp.
>
> This leads me to ask two questions:
>
> Would my proposed package-vc-dev command, plus this, add up to the 
> currently proposed package-vc-install command?

I did not quite understand the point of `package-vc-dev', so I cannot
comment on it.  What I can say that `package-vc-install' "minus"
"site-lisp" would be a function that would just use package metadata to
clone repositories into a specific directory.

> Would this be just what the user wants
> for preserving patches in packages installed from the release?

Again, I am not sure.

> By the way, GNU ELPA and NonGNU ELPA both have a repo which
> holds the current released version of each package.  Imagine
> a package-vc-release command that does a checkout of the
> released package from ELPA, in the same way.  That would help
> people add patches to the released version, and would merge
> changes when a new version is released.