If you don't know it is, hashin
is a Python command line tool for updating your requirements file's packages and their hashes for use with pip install
. It takes the pain out of figuring out what hashes each package on PyPI has. It also takes the pain out of figuring out what version you can upgrade to.
In the 0.14.0 release (changelog) there are a bunch of new features. The most exciting one is --update-all
. Let's go through some of the new features:
Update all (--update-all
)
Suppose you want to bravely upgrade all the pinned packages to the latest and greatest. Before version 0.14.0 you'd have to manually open the requirements file and list every single package on the command line:
$ less requirements.txt
$ hashin Django requests Flask cryptography black nltk numpy
With --update-all
it's the same thing except it does that reading and copy-n-paste for you:
$ hashin --update-all
Particularly nifty is to combine this with --dry-run
if you get nervous about that many changes.
Interactive update all (--interactive
)
This new flag only makes sense when used together with --update-all
. Used together, it basically reads all packages in the requirements file, and for each one that there is a new version it asks you if you want to update it or skip it:
It looks like this:
$ hashin --update-all --interactive
PACKAGE YOUR VERSION NEW VERSION
Django 2.1.2 2.1.3 ✓
requests 2.20.0 2.20.1 ✘
numpy 1.15.2 1.15.4 ?
Update? [Y/n/a/q/?]:
You can also use the aliases hashin -u -i
to do the same thing.
Support for "extras"
If you want to have requests[security]
or markus[datadog]
in your requirements file, hashin used to not support that. This now works:
$ hashin "requests[security]"
Before, it would look for a package called verbatim requests[security]
on PyPI which obviously doesn't exist. Now, it parses that syntax, makes a lookup for requests
and when it's done it puts the extra syntax back into the requirements file.
Thanks Dustin Ingram for pushing for this one!
Atomic writes
Prior to this version, if you typed hashin requests flask numpy nltkay
it would go ahead and do one of those packages at a time and effectively open and edit the requirements file as many times as there are packages mentioned. The crux of that is that if you, for example, have a typo (e.g. nltkay
instead of nltk
) it would crash there and not roll back any of the other writes. It's not a huge harm but it certainly is counter intuitive.
Another place where this matters is with --dry-run
. If you specified something like hashin --dry-run requests flask numpy
you would get one diff per package and thus repeat the diff header 3 (excessive) times.
The other reason why atomic writes is important is if you use hashin --update-all --interactive
and it asks you if you want to update package1
, package2
, package3
, and then you decide "Nah. I don't want any of this. I quit!" it would just do that without updating the requirements file.
Better not-found errors
This was never a problem if you used Python 2.7 but for Python 3.x, if you typoed a package name you'd get a Python exception about the HTTP call and it wasn't obvious that the mistake lies with your input and not the network. Basically, it traps any HTTP errors and if it's 404
it's handled gracefully.
(Internal) Black everything and pytest everything
All source code is now formatted with Black which, albeit imperfect, kills any boring manual review of code style nits. And, it uses therapist
to wrap the black
checks and fixes.
And all unit tests are now written for pytest
. pytest
was already the tool used in TravisCI but now all of those self.assertEqual(foo, bar)
s have been replaced with assert foo == bar
.
Comments