Shouldn't it be documented that the keyword argument "license_file" is
supported as an agrument in setup()? It's currently not listed in the
Writing setup(..., license_file="LICENSE.txt", ...) has actually the
same effect as adding "license_file" to the metadata section of
setup.cfg. Such an elementary functionality as adding a license_file to
a package should be considered to be a standard functionality of
setup(), that should be properly documented. Right now, the users get's
the impression, that it's necessary to use a setup.cfg file, if they
want to use the license_file property.
Greetings all! I am happy to announce that after a long hiatus, there is
a pre-release of pipenv available for testing.
You can read the full announcement at
I look forward to your feedback.
Software Engineer | Pipenv Maintainer
Canonical, Ltd. | Python Packaging Authority
dan.ryan(a)canonical.com | dan(a)danryan.co
A new beta release of pip, 20.2b1 has been released! You can install
it by running `python -m pip install --upgrade --pre pip`.
This release is mainly intended for users interested in testing the
new resolver code (available via the `--unstable-feaure=resolver`
option to pip). Apart from the resolver, there are only a couple of
changes over the current stable (20.1.1) release of pip. However, as
we move closer to having a feature-complete release of the new
resolver, we wanted to provide an updated snapshot of the new resolver
functionality, to allow people interested in helping us with the
testing to get access to the latest changes that have been made.
Thanks to everyone who has contributed to this release, and in
particular to all of the people who have tested and provided feedback
on the new resolver so far!
On behalf of the pip maintainers,
It's Bernard and Nicole from the pip Team.
The team is working on the improving the way that pip resolves package
We're asking for your help to test pip's new resolver.
We're especially interested in hearing from people who have projects
with complex dependencies.
By complex dependencies we mean projects that look like this:
- have at least 10 package dependencies
- some package are pinned to specific versions
- that you always have a dependency issue when installing it
- you have to put in hacks, workarounds, or fixes
Currently, we’re trying to discover all the ways in which pip‘s
dependency resolver fails, so that we can work out what error messages
and/or debugging information we should display.
You can find out what we'd like you to do on this blog post:
If you're into social media, we'd appreciate if you'd boost these
You can sign-up for other UX Studies also:
If you've got any questions, reply here off or on-list.
Bernard & Nicole pip Team UX
Bernard Tyers, User research & Interaction Design
Sane UX Design
PGP Key: keybase.io/ei8fdb
I am currently working with the Python Foundation, and Open Technology Fund
The https://executablebooks.org project has a jupyter-book excutable that wraps sphinx via a console_script. We'd like to ensure UTF8 everywhere when windows users run that script. Would be grateful for a pointer on how best to accomplish this.
I'm using the current version of Python on both a MacBook Pro and an iMac.
I'm trying to import the pygame module from the terminal.
The problem is that it's applying the module to Python 2.7 that came with
Is there a way that I can correct the path so that every command I enter in
the Terminal gets applied to whichever current version of Python that I'm
Let me know.
On behalf of the PyPA, I am pleased to announce a beta release of pip,
pip 20.1b1 has been released.
The highlights for this release are:
* Significant speedups when building local directories, by changing
behavior to perform in-place builds, instead of copying to temporary
* Significant speedups in `pip list --outdated`, by parallelizing
network access. This is the first instance of parallel code within
* A new `pip cache` command, which makes it possible to introspect and
manage pip's cache directory.
* Better `pip freeze` for packages installed from direct URLs, enabled
by the implementation of PEP 610.
We would be grateful for all the testing that users could do, to ensure
that when pip 20.1 is released, it's as solid as we can make it.
This release also contains an alpha version of pip's next generation
resolver. It is *off by default* because it
*unstable and notready for everyday use*.
As with all pip releases, a significant amount of the work was
contributed by pip's user community. Huge thanks to all who have
contributed, whether through code, documentation, issue reports and/or
discussion. Your help keeps pip improving, and is hugely appreciated.
Specific thanks go to Mozilla (through its Mozilla Open Source Support
Awards) <https://www.mozilla.org/en-US/moss/> and to the Chan Zuckerberg
Initiative <https://chanzuckerberg.com/eoss/> DAF, an advised fund of
Silicon Valley Community Foundation, for their support that enabled the
work on the new resolver.