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:

> Philip Kaludercic [2022-02-15 17:13:56] wrote:
>> 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?
>
> Not sure what "display" has to do with it.  The name of the package is
> beyond our control.  So the choice is not what to display but what name
> to give to the directory.  `<pkg>` is a name that already works.
> `<pkg>-devel` is a name that currently doesn't work.
>
> In any case, this is not an important issue, I think (at least, as long
> as "devel" is not a valid version name).

I now understand the confusion, I had assumed we were discussion how
package names are presented by completing-read calls, without
considering that `package-desc-full-name' is invoked elsewhere too.
In that case, yes, the change should be reverted.

>>>>> 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.
>
> That's already the case if `~/.emacs.d/elpa/devel` is in
> `package-directory-list`, so I don't understand how that relates to what
> we're discussing.

Unless I am mistaken, `package--make-autoloads-and-stuff' is currently
only invoked by `package-unpack', that in turn is only called by the
`package-install-from-*' functions.  Am I missing something, or how
would the autoload file be generated if I just place a repository into
~/.emacs.d/elpa/devel?

Of course if this complicates things too much, I won't insist on it, as
alternative solutions exists.

>> One case where this could be useful for anyone using submodules in
>> a versioned configuration.
>
> Again, I don't understand the relationship.  Maybe if you could give
> a concrete example scenario?

Say a repository consists of only an init.el, and a few submoduled git
repositories under /elpa/devel/.  These wouldn't include the -pkg.el or
-autoload.el files, so they should be generated as soon as necessary.

>>> 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?
>
> Yes.  Depending on how good "-<foo>-" is, we may want to add shorter
> aliases, of course, but I think that using a `package-<foo>-` prefix
> will help clarify the design.

Ok.

>
>         Stefan
>

-- 
        Philip Kaludercic