all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@posteo.net>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] epm.el: A CLI tool for package.el
Date: Thu, 04 May 2023 10:24:23 +0000	[thread overview]
Message-ID: <874jospf6w.fsf@localhost> (raw)
In-Reply-To: <u2tj7b$10i4$1@ciao.gmane.io>

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>


  reply	other threads:[~2023-05-04 10:22 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-11 10:36 Useful package? Compat.el Timothy
2021-10-11 14:28 ` Russell Adams
2021-10-11 14:40   ` Timothy
2021-10-11 18:04     ` Joost Kremers
2023-01-27 13:23 ` [POLL] Use compat.el in Org? (was: Useful package? Compat.el) Ihor Radchenko
2023-01-27 13:34   ` [POLL] Use compat.el in Org? Bastien Guerry
2023-01-27 20:38     ` Tim Cross
2023-01-27 21:38       ` Daniel Mendler
2023-01-27 22:29         ` Samuel Wales
2023-01-28 16:04   ` [POLL] Use compat.el in Org? (was: Useful package? Compat.el) Kyle Meyer
2023-01-30 11:35   ` Greg Minshall
2023-01-30 19:33     ` Ihor Radchenko
2023-01-30 19:40       ` Greg Minshall
2023-01-30 21:38         ` Daniel Mendler
2023-04-01 10:31   ` [PATCH] Add compat.el support to Org (was: [POLL] Use compat.el in Org? (was: Useful package? Compat.el)) Ihor Radchenko
2023-04-01 11:38     ` Daniel Mendler
2023-04-01 14:20       ` Max Nikulin
2023-04-02  8:52         ` Ihor Radchenko
2023-04-02 15:31           ` Max Nikulin
2023-04-02 16:04             ` Ihor Radchenko
2023-04-02 16:37     ` Max Nikulin
2023-04-02 17:00       ` [PATCH v2] " Ihor Radchenko
2023-04-03  8:46         ` [PATCH v3] " Ihor Radchenko
2023-04-08 11:15         ` [PATCH v2] " Max Nikulin
2023-04-08 11:41           ` Ihor Radchenko
2023-04-08 16:37             ` Max Nikulin
2023-04-13 12:42               ` Ihor Radchenko
2023-04-17 17:20                 ` Max Nikulin
2023-04-20  9:27                   ` Ihor Radchenko
2023-04-28 15:27                     ` Max Nikulin
2023-04-30 10:39                       ` [PATCH v4] " Ihor Radchenko
2023-05-03 12:14                         ` [PATCH] epm.el: A CLI tool for package.el Max Nikulin
2023-05-04 10:24                           ` Ihor Radchenko [this message]
2023-05-04 16:16                             ` Max Nikulin
2023-05-05  9:39                               ` Ihor Radchenko
2023-05-06  6:39                         ` [PATCH v4] Add compat.el support to Org (was: [POLL] Use compat.el in Org? (was: Useful package? Compat.el)) Max Nikulin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874jospf6w.fsf@localhost \
    --to=yantar92@posteo.net \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.