Perhaps slightly off-topic, but I have sometimes wondered if
pip could not be made somewhat friendlier for the absolute newbie
and the classroom context.
Some concrete proposals.
1. Add a function `pip` to the interactive interpreter
(similar to how `help` is available).
def pip(args):
import sys
import subprocess
subprocess.check_call([sys.executable, "-m", "pip"] + args.split())
This allows people to install something using pip as long as they have a
Python prompt open, and avoids instructors to have to deal with
platform-specific
instructions for various shells. Also avoids confusion when multiple
Python interpreters
are available (it operates in the context of the current interpreter.)
2. Add to Pypi package webpages a line like:
To install, execute this line in your Python interpreter:
pip("install my-package --user")
Make this copyable with a button (like Github allows you to copy the repo
name).
3. Add the notion of a "channel" to which one can "subscribe".
This is actually nothing new, just a Pypi package with no code and just
a bunch of
dependencies. But it allows me to say: Just enter:
pip("install stephans-awesome-stuff --user")
in your Python and you get a bunch of useful stuff.
Stephan
2017-10-29 8:54 GMT+01:00 Nick Coghlan <ncogh...@gmail.com>:
> On 29 October 2017 at 15:16, Guido van Rossum <gu...@python.org> wrote:
>
>> Why? What's wrong with pip install?
>>
>
> At a technical level, this would just be a really thin wrapper around 'pip
> install' (even thinner than ensurepip in general, since these libraries
> *wouldn't* be bundled for offline installation, only listed by name).
>
>
>> Why complicate things? Your motivation is really weak here. "beneficial"?
>> "difficult cases"?
>>
>
> The main recurring problems with "pip install" are a lack of
> discoverability and a potential lack of availability (depending on the
> environment).
>
> This then causes a couple of key undesirable outcomes:
>
> - folks using Python as a teaching language have to choose between
> teaching with just the standard library APIs, requiring that learners
> restrict themselves to a particular preconfigured learning environment, or
> make a detour into package management tools in order to ensure learners
> have access to the APIs they actually want to use (this isn't hypothetical
> - I was a technical reviewer for a book that justified teaching XML-RPC
> over HTTPS+JSON on the basis that xmlrpc was in the standard library, and
> requests wasn't)
> - folks using Python purely as a scripting language (i.e without app level
> dependency management) may end up having to restrict themselves to the
> standard library API, even when there's a well-established frequently
> preferred alternative for what they're doing (e.g. requests for API
> management, regex for enhanced regular expressions)
>
> The underlying problem is that our reasons for omitting these particular
> libraries from the standard library relate mainly to publisher side
> concerns like the logistics of ongoing bug fixing and support, *not* end
> user concerns like software reliability or API usability. This means that
> if educators aren't teaching them, or redistributors aren't providing them,
> then they're actively doing their users a disservice (as opposed to other
> cases like web frameworks and similar, where there are multiple competing
> options, you're only going to want one of them in any given application,
> and the relevant trade-offs between the available options depend greatly on
> exactly what you're doing)
>
> Now, the Python-for-data-science community have taken a particular
> direction around handling this, and there's an additional library set
> beyond the standard library that's pretty much taken for granted in a data
> science context. While conda has been the focal point for those efforts
> more recently, it started a long time ago with initiatives like Python(x,
> y) and the Enthought Python Distribution.
>
> Similarly, initiatives like Raspberry Pi are able to assume a particular
> learning environment (Raspbian in the Pi's case), rather than coping with
> arbitrary starting points.
>
> Curated lists like the "awesome-python" one that Stephan linked don't
> really help that much with the discoverability problem, since they become
> just another thing for people to learn: How do they find out such lists
> exist in the first place? Given such a list, how do they determine if the
> recommendations it offers are actually relevant to their needs? Since
> assessing a published package API against your needs as a user is a skill
> that has to be learned like any other, it can be a lot easier to get
> started in a more prescriptive environment that says "This is what you have
> to work with for now, we'll explain more about your options for branching
> out later".
>
> The proposal in this thread thus stems from asking the question "Who is
> going to be best positioned to offer authoritative advice on which third
> party modules may be preferable to their standard library counterparts for
> end users of Python?" and answering it with "The standard library module
> maintainers that are already responsible for deciding whether or not to
> place appropriate See Also links in the module documentation".
>
> All the proposal does is to suggest taking those existing recommendations
> from the documentation and converting them into a more readibly executable
> form.
>
> I'm not particularly wedded to any particular approach to making the
> recommendations available in a more machine-friendly form, though - it's
> just the "offer something more machine friendly than scraping the docs for
> recommendation links" aspect that I'm interested in. For example, we could
> skip touching ensurepip or venv at all, and instead limit this to a
> documentation proposal to collect these recommendations from the
> documentation, and publish them within the `venv` module docs as a
> "recommended-libraries.txt" file (using pip's requirements.txt format).
> That would be sufficient to allow straightforward 3rd party automation,
> without necessarily committing to providing such automation ourselves.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
