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

[Stefan Monnier]

> The -devel doesn't necessarily indicate that directly, I just meant it
> was worth somehow explicitly indicating that this is a VCS-package.

But what I'm saying is: why not put no "-*" at all, since that's what
`package.el` has been using so far for those cases (tho these had to be
"installed" by hand)?

>> IIUC for those VCS-installed packages we generate the <pkg>-pkg.el file
>> ourselves, so it should be fairly easy to make sure that file provides
>> the needed info so we don't need to guess.
>
> Yes, but again, if I just clone a project into elpa/devel, this won't
> work.  It could be argued that this shouldn't be supported because it is
> a different issue, and the elpa/... directories maintained by
> package.el, but in that case I would like some other way to have
> package.el manage non-versioned local source.

I'm sorry, I don't understand what you're saying here.  Who&how does
"just clone a project into elpa/devel" and what do you mean by "elpa/devel"?

>> For the rare cases where this is not the case, the `:main-file` property
>> of the package spec should tell us which file it is.  I'd rather not try
>> and guess.
> Ok, I didn't know that :main-file was propagated into the package
> specification.  In that case there should be no issue.

The package specification is written by hand into `elpa-packages`, so
nothing propagates it from elsewhere into the spec, AFAICT (other than
a human, that is).

I think we need to clarify our assumptions because we seem to fail to
understand each other.

The way I imagine it working goes as follows:

- `elpa-admin.el` will be changed so that the spec from `elpa-packages`
  is propagated into the metadata in `archive-contents`.

- when VCS-installing a package, we basically start with that spec (tho
  it can be reduced to a simple URL in many cases).

- those VCS-packages are installed by cloning them into a directory with
  name `<pkg>`.

- During installation we auto-produce a `<pkg>-pkg.el` file (and the
  `<pkg>-autoloads.el`, of course), so that `package-activate-all` will
  do the right thing.

- We somehow/somewhere/somewhen update these `<pkg>-pkg.el` and
  `<pkg>-autoloads.el` files sometimes after a `git pull` or equivalent.
  A simple way would be to provide some `package-vcs-update` command or
  somesuch (which would also recompile the changed `.el` files).

- We could also arrange for `package-activate` to try and detect the
  case where the files were updated manually via `git pull` and emit
  a warning prompting the user to refresh that package's generated files.
  This same command which refreshes the generated files of
  a VCS-installed package could probably be used by users who want to do
  the `git clone` by hand.

BTW, I think we should choose some `package-<foo>-` prefix for the
vars&functions related to this new "install from VCS" functionality.


        Stefan