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. ]]]
>
>   > > I'm not quite sure what that means -- what is the "foundation", and why
>   > > is there a hurry to merge it in?
>
>                                                          Of course this
>   > shouldn't be rushed, but I believe the branch is currently in a
>   > functional state that would be useful.
>
> That may be true -- I don't know, so I won't dispute it.
> However, before we merge it in we should get the command
> interface right.

FYI since our last exchange I have implemented the features necessary to
check out the commit used to create the tarball that ELPA server would
distribute.  This is done when you invoke `package-vc-install' with a
prefix argument.

>   > > 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.
>
> I find it hard to understand that last sentence.  What does it mean,
> "what version was used to release a package"?

I meant to say "revision", sorry about that.  But as I said above, this
has now already been implemented.

> Do you mean, "what version _in the upstream repo_ was copied into the
> ELPA repo"?  If so, I think that is a spurious problem -- we don't
> need to know which upstream version.  At least, not for this purpose.
> It might be useful to keep track of that for some other purpose; if
> so, I have nothing against doing so.  But it isn't related to this
> feature.
>
> ELPA has its own repo.  By definition, the current version of the
> package its latest version of in the ELPA repo.  To get the package
> source in a repo, for the current ELPA version, should simply check it
> out from the ELPA repo.  This has nothing to do with the ELPA repo.
>
> These two operations (check out from ELPA repo, and check out from
> upstream repo) are different in purpose.  It is important to avoid
> confusion about whether the checkout contains the current version
> or the upstream repo.

I have my doubts as to how significant of a difference these two things
are.  But this isn't to be decided in package-vc.el anyway, instead the
package archive (in our case GNU ELPA and NonGNU ELPA) generates a list
of package specifications, which can either point upstream or to ELPA.

> So they should have different command names.

There are more and more packages that are automatically synchronised, as
is the case by default with NonGNU ELPA.  In that case, there is no
significant difference between the two, and introducing such a thing
would just bring about confusion.

What can be argued is that packages from GNU ELPA that are not
automatically synchronised ought to point to elpa.git.  But as I have
said, that is a decision that can be made at any point, unrelated to
package-vc.el, as this is just the "input" that an ELPA server provides.

> Also, the results should be distinguishable by directory name.  A
> checkout from the upstream repo should have `upstream' in its name,
> while a checkout from the ELPA repo should have `current' in its name.
> This too will help users avoid misremembering which version they
> are operating on.

Is this a point related to the separation of upstream and ELPA
repositories, or one in general.

> I think we should separate checking out the upstream source from a
> repo and "installing" for use by default in your Emacs.  There are
> several reasons to want to see the upstream source, different
> scenarios.

> * A user might want to start using the upstream version by default.
>
> * A user might want to work on changes in the upstream version
> and try those changes from time to time, but not most of the time.
>
> * A user who has started using the upstream version by default
> might wish to disable use of that version because it has some flaw,
> and reemable it later.
>
> So there needs to be a way to enable and disable use of a specific
> ELPA version checkout of a package.

I believe that package.el already supports this via `package-load-list'.

> I think we should separate the operations of checking out a version
> from a repo, and enabling or disabling that version for use by Emacs.
>
>   > > 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",
>
> How about `checkout' instead of `repo'?  `package-checkout' to check
> out from the ELPA repo, and either `package-upstream-checkout' or
> `package-dev-checkout' for the upstream repo.

As Stephan has pointed out that "-checkout" is misleading since it
sounds like a command that would just clone the repository without
activating it as a package.  FWIW this is a fine functionality to have
and would be trivial to implement.

> We could also have `package-enable-version' and `package-disable-version'
> to enable and disable actual use of a package checkout by Emacs.
>
> Is it feasible to specify which version of which package by selecting
> a directory containing a checkout, or by putting point in a list of
> such checkouts?  That would be a convenient interface, I think.

As mentioned above, I believe that `package-load-list' is the right tool
for the job.  In general, package-vc.el is just an alternative method if
fetching and initialising a package, the rest is just done taken care of
by package.el, that isn't too concerned about where the package came from.