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

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

I get that, my question still remains.  Or to rephrase it, what is the
advantage of displaying package names with the same names as the 
directories they are found in?

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

What I meant was that all directories in ~/.emacs.d/elpa/devel could be
automatically detected and loaded.  One case where this could be useful
for anyone using submodules in a versioned configuration.

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

Yes, exactly (and I agree with all of the above too).  Something like
checking the mtime of files and/or comparing the auto-loaded files on
saving or on startup.

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

If it is possible to extract the relevant functionality form package.el
to package-<foo>.el, then of course, but I can also try to stick to this
otherwise.  Do you think this should also include renaming package-fetch?

>
>         Stefan
>

-- 
        Philip Kaludercic