Thank you for the excellent suggestions. The specifics will be hashed out in the workshop/survey. If there are other high-level suggestions, please feel free to share them. Regards, Shamika On Wed, Apr 20, 2022 at 3:59 PM Matthias Bussonnier < bussonniermatthias@gmail.com> wrote:
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