Yes, that was vaguely worded.

I don't have anything against a set of libraries that would not
require pip, but my impression is that any such effort would likely
use pip in some form needs  a minimal set of changes or stabilisation
guarantees that need to be made in pip.

As conda is also in this thread, if this goes only to a RFC/PEP that
pip/conda agrees on for interoperability, that would be a huge step
forward.

It's not yet time to dive into details, but thinking about error
messages, and downloading progress/user feedback in non-terminal
applications might lead to quite some discussions.
--
M





On Wed, 20 Apr 2022 at 12:25, Paul Moore <p.f.moore@gmail.com> wrote:
>
> On Wed, 20 Apr 2022 at 10:25, Matthias Bussonnier
> <bussonniermatthias@gmail.com> wrote:
>
> > Package installation by non-programmer (who don't use the CLI) is
> > becoming more and more common/difficult. Could we have a pip API to
> > allow simpler creation of packaging GUI ?
>
> I'd agree with this but reframe it as "how do we encourage/support the
> development and adoption of a library (or libraries) that provides a
> programmatic API for the installation tasks that pip currently does?"
> If we decouple this work from the pip project, we're more likely to
> find a way to develop and maintain this sustainably.
>
> But yes, this would be a good topic to consider (and we should defer
> worrying about details for now).
> Paul