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

[Richard Stallman]

[[[ 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.

  > 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 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?

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

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.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)