Re: feature/package-vc has been merged

[Philip Kaludercic]

Rudolf Adamkovič <salutis@me.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> That said, When I updated my config to install from VC, I noticed
>>> that `elpa' in `.emacs.d' now contained two versions of the packages,
>>> one from `package' and one from `package-vc'.
>>
>> This seems like an issue of what perspective one takes.  I don't see
>> package-vc as an "upgrade" over package, but as an alternative backend
>> for fetching source code.  Not even I plan to use it for everything,
>> rather I'd install a source package when I am hacking on some package,
>> and when I have sent out the patches and am done with it, I'd remove
>> the source package and be left with the previous installation.
>
> I like the backend idea, but the two systems, non-VC and VC, define
> separate lists of selected packages.  But then, what happens when the
> user selects the same package in both lists?  Will that lead to any
> problems?  If so, then we should not allow the user to do that, or deal
> with it in some way.

No, I have "arrogantly" made sure that source packages are prioritised
over regular (tarball, built-in, system) packages.

>>> As a side note, you mentioned that `package-install' works for both
>>> "normal" and VC packages?  I guess `package-autoremove' does that too?
>>> I looked at the documentation for both and they mention just
>>> `package-selected-packages'.
>>
>> I don't think I said "package-install works for both normal and VC
>> packages"?  package-install fetches a tarball, package-vc-install
>> fetches a repository?
>
> I apologize for confusion.
>
> Perhaps you said that for `package-update'?  (I remain a bit confused
> about which commands apply to both VC and non-VC packages.)

Unless I have forgotten something, the only commands from package.el
that apply to both package.el and package-vc.el are

- package-delete
- package-update
- package-update-all

>>> And speaking of `-autoremove', should we also add `-vc-autoremove'?
>>
>> I don't think so, because -autoremove is for removing non-selected
>> packages, while all source packages are selected (you'll find that
>> package-vc uses regular tarball packages if dependencies have to be
>> installed).
>
> Really?  I thought VC `-install' works like the non-VC kind, meaning it
> does not select anything, just installs a package so that the user can
> quickly try it.  But you say "all source packages are selected".

If you package-install a package, it is selected and won't be removed.
Quote the docstring:

  Mark the installed package as selected by adding it to
  ‘package-selected-packages’.

The only non-selected packages are all transitive dependencies.

>>> For the only problem I have, I could not install `geiser'.  I got
>>> "user-error: Package has no VC data", and I kept wondering what the user
>>> should do in this situation.  I had no idea where to look.
>>
>> That sounds wrong, there seems to be a specification in
>> elpa-packages.eld:
>>
>>   ("geiser" :url "https://gitlab.com/emacs-geiser/geiser.git"; :lisp-dir
>>   "elisp" :readme "readme.org" :doc "doc/geiser.texi")
>>
>> Maybe this is related to MELPA?  They don't have package specification
>> lists yet, and if their package is prioritised (due to their versioning
>> scheme), maybe this could confused package-vc?
>
> I tried the following two experiments, starting from:
>
> (with-eval-after-load 'package
>   (add-to-list
>     'package-archives
>     '("melpa" . "https://melpa.org/packages/";))
>   (add-to-list
>     'package-archives
>     '("melpa-stable" . "https://stable.melpa.org/packages/";)))
>
> Experiment 1:  Add MELPA to the end of the list.
>
> (with-eval-after-load 'package
>   (add-to-list
>     'package-archives
>     '("melpa" . "https://melpa.org/packages/";)
>     t)  ; <------ `t' means the end of the list
>   (add-to-list
>     'package-archives
>     '("melpa-stable" . "https://stable.melpa.org/packages/";)
>     t)) ; <------ `t' means the end of the list
>
> This *did not* help.
>
> Experiment 2: Comment out MELPA.
>
> ;; (with-eval-after-load 'package
> ;;   (add-to-list
> ;;     'package-archives
> ;;     '("melpa" . "https://melpa.org/packages/";))
> ;;   (add-to-list
> ;;     'package-archives
> ;;     '("melpa-stable" . "https://stable.melpa.org/packages/";)))
>
> This *did* help.
>
> If the user has MELPA at the end of the list, it should just work.  So,
> that needs fixing.  But the question becomes, what should happen if the
> user has MELPA at the beginning of the list.  VC could fail, but it
> could also proceed, silently or with a message.

You can see what is going on in `package-vc--desc->spec'.  What we could
do is replace the

  (if (package-desc-archive pkg-desc)
       (alist-get (intern (package-desc-archive pkg-desc))
                  package-vc--archive-spec-alist)
     (mapcan #'append (mapcar #'cdr package-vc--archive-spec-alist)))

with just

  (mapcan #'append (mapcar #'cdr package-vc--archive-spec-alist))

but that might be confusing in other situations (the code here is
preparing an alist of package names to specifications).

>>> I will try more packages in the coming days or weeks!
>>
>> Very appreciative.  But this is a good sign that after bug#59109 has
>> been resolved, the changes can be applied back onto master.
>>
>>> P.S. The documentation for the `package-vc-selected-packages' variable
>>> contains a typo "... you cal also use ...".
>>
>> Will fix, thanks!
>
> Super!
>
> Also, the documentation for the `package-vc-install' function needs some
> blank lines between paragraphs.  :)

I don't know, is that conventional?  I believe to have seen both, but
never knew which was the "right" way.

> Rudy