Max Nikulin <maniku...@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>
