Re: [PATCH] epm.el: A CLI tool for package.el

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> Good idea. Although, we should not overdo this package management thing.
>> If we really need complex functionality here, we should better just use
>> cask/eldev instead of re-inventing the wheel.
>
> I have not tried cask or eldev, so I can not reason on supposed workflow.

Cask basically solves dependency management, including tracking outdated
dependencies. See
https://cask.readthedocs.io/en/latest/guide/usage.html#quickstart
It can also be used from Makefile.
The downside is that it has to be installed separately.

>> Are you willing to improve the draft to be ready for upstream?
>
> See the attachment. Interface is subject to change to better fit 
> particular use cases.

Thanks!

>> 2. By ordinary users, not necessarily familiar with GNU make and all the
>>     associated build process conventions.
>
> For those who are not familiar with convention any target may be 
> specified in docs, keeping usual meaning of the default "all" target.

I am mostly concerned about the existing users who are already settled
on running the default "make". Their workflow will be broken with your
suggestion. 

>> However, make repro and
>> optionally make docs should avoid re-using user packages as it may cause
>> inconsistent results if the `package-user-dir' is messed up.
>
> I agree concerning "make repro", but unsure for docs.

I am also unsure about docs. Might be either way.

> In general I agree that strategy may depend on specified target. The 
> only issue that make allows to specify several targets.

I am not sure what will be the problem there. make all is also
technically several targets. And running something like
 make compile repro is a bit silly anyway.

> An I am unsure concerning user prompt.

My main concern is for the users who changed their elpa directory
location. They might run into issues unexpectedly.

>> I think that it is stretching a bit beyond the complexity we should
>> allow within Org build system. In your scenario, I can simply do
>> make cleanpkg and re-download the latest dependencies.
>
> I would prefer clear error message that package version is not 
> satisfactory. However such feature may be added later.

I think package.el technically suffers from the same problem. I do not
think that we need to work around it ahead of Emacs. Not until it proves
necessary. (and even then, we should better contribute upstream anyway)

>>> #!/bin/sh
>>> ":"; # -*- mode: emacs-lisp; lexical-binding: t; -*-
>>> ":"; exec emacs --script "$0" "$@"
>> 
>> Let's not lock to bash. AFAIK, our makefiles can currently work on
>> Windows. Using /bin/sh will lead to regression.
>
> It is POSIX shell, not BASH. I am unsure if make can be used on windows 
> when e.g. cygwin is not available. Makefiles are full of POSIX tool 
> invocations.

I thought that more portable way is using "env".

> +(defun epm-nonempty-p (s)
> +  (and s (not (string-empty-p s))))

Can just use `seq-empty-p'.

> +  ;; TODO (load site-run-file 'no-error 'no-message)
> +  ;; may be necessary to load elpa-* deb packages when -Q option
> +  ;; is used. See Info node "(elisp) Init File".

Given the explanation in the top comment, is this necessary?

> +(defun epm-library-unavailable-p (lib)
> +  (unless (locate-library lib)
> +    lib))

> +(defun epm-missing (libs)
> +  ;; TODO consider `require' catching load errors
> +  (delq nil (mapcar #'epm-library-unavailable-p libs)))

Maybe just (cl-remove-if #'locate-library libs)?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>