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.
PyPi does not allow duplicate file names -- this makes lots of sense,
because you really don't want people to go to PyPi one day and grab a file,
and then go there another day, grab a file with exactly the same name, and
have it be a different file.
We are all too human, and make mistakes when doing a release. All to often
someone pushed a broken file up to PyPi, often realizes it pretty quickly
-- before anyone has a chance to even download it (or only the dev team as,
In fact, I was in a sprint last summer, and we decided to push our package
up to PyPi -- granted, we were all careless amateurish noobs, but we ended
up making I think 4! minor version bumps because we had done something
stupid in the sdist.
Also -- the latest numpy release got caught in this, too:
* We ran into a problem with pipy not allowing reuse of filenames and a
resulting proliferation of *.*.*.postN releases. Not only were the names
getting out of hand, some packages were unable to work with the postN
So -- I propose that PyPi allow projects to replace existing files if they
REALLY REALLY want to.
You should have to jump through all sorts of hoops, and make it really
clear that it is a BAD IDEA in the general case, but it'd be good to have
it be possible.
After all -- PyPi does not take on responsibility for anything else about
what's in those packages, and Python itself is all about "we're all
consenting adults here"
I suppose we could even put in some heuristics about how long the file as
been there, how many times it's been downloaded, etc.
Just a thought.....I really hate systems that don't let me roll back
mistakes, even when I discover them almost immediately...
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
I've got two projects: mynamespace.myprojectA and mynamespace.myprojectB
myprojectB depends on myprojectA. I'm using setuptools 0.6c8 to manage both
Both projects are registered using 'setup develop'. Both projects are
accessible from an interactive interpreter:
PS C:\Users\me\projects> python
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]
Type "help", "copyright", "credits" or "license" for more information.
>>> import mynamespace.myprojectA
>>> import mynamespace.myprojectB
>>> from mynamespace.myprojectA import mymoduleZ
However, when I run 'setup test' in myprojectB, the tests fail with
File ".mymoduleZ.py", line NNN, in [some context]
from mynamespace.myprojectA.mymoduleZ import MyClassC
ImportError: No module named myprojectA.mymoduleZ
In setup.py, the test_suite is nose.collector.
I searched and couldn't find anyone else with this problem. Is this a
supported configuration? Is there something I can do to make tests work
with interdependent projects with the same root namespace?
If there's not something obvious I should be doing differently, I'm happy to
put together a minimal test case that reproduces the problem. Any
suggestions are appreciated.
Jason R. Coombs
Pradyun Gedam is giving a talk to a local meetup group in 90 minutes on
how pip works. You can watch via GoToMeeting.
> pip is the package manager for the Python ecosystem, but what actually happens when you "pip install foo"? This talk explores what pip does to install your packages.
When: April 7th, 9:00 p.m - 10:00 p.m. India time
It'll likely be recorded and be available on YouTube afterward.