Changes:
e8d1d57145...v0.10
Using a specific version release of django-browserid (vs the Git zip
archive for a specific revision) means peep doesn't have to re-download
the package each time.
Changes:
e8d1d57145...v0.11.1
This will fix the spurious "Setting BROWSERID_VERIFY_CLASS not found"
errors in logs, as well as possibly help with people getting logged out
intermittently. It also brings us up to the latest django-browserid
release, which means updating later to a (yet to be released) Django 1.8
compatible version of django-browserid should be much easier.
Using a specific version release of django-browserid (vs the Git zip
archive for a specific revision) also means peep doesn't have to
re-download the package each time.
This is a no-op, the v0.6 release tag corresponds to the same revision,
it just avoids peeps SHA special-casing which causes continual
re-installation of the package & subsequent Travis cache invalidation.
https://github.com/jeads/datasource/releases/tag/v0.6
Changes:
f236a3487e...1.1
Using a specific version release of treeherder-client (vs the Git zip
archive for a specific revision) also means peep doesn't have to
re-download the package each time.
We're no longer using the vendor directory & this script wasn't entirely
reliable anyway, so let's remove it. The virtualenv package can be
removed from dev.txt, since virtualenv is installed globally, and
nothing inside our virtualenv (which is where the packages in dev.txt
end up) needs a local installation of it.
This differentiation was only useful when explaining which packages
could be listed in which requirements file (since compiled packages
could not be added to checked-in.txt). Now that all packages are peep
installed, common.txt contains both pure and compiled packages.
Previously, the requests package had to be listed in dev.txt even
though it was in the vendor directory, since it was used by conftest.py
before the vendor directory was added to the Python path. Now that the
packages in checked-in.txt have been moved to common.txt, 'requests' is
listed in two requirements files that are peep installed, so we can
remove the dupe.
Now that we're using virtualenvs and peep to manage packages in
production, there's no need to use an in-repo vendor directory. As
such, all packages that were in checked-in.txt have been moved to
common.txt, so they will now be peep installed during deployment/testing
and also during the provision of the Vagrant environment.
The whole point of peep is that it errors out if (a) hashes aren't
specified for a package, or (b) the provided hash is incorrect. As
such before we can start using peep, we must add the hashes. The
requirements files are still compatible with pip, since it just
treats them like any other comment.
We're not currently using socketio - and if we start doing so in the
future we'll likely want to update to a newer version/adjust the
implementation anyway. Removing the dependencies from common.txt speeds
up the pip install on Travis. The old files will still be in version
control should we wish to refer to them :-)
The packages in this file are already a mixture of pure and compiled
packages. It's not worth moving the pure packages to checked-in.txt,
since we'll eventually be removing checked-in.txt and the associated
vendor/ and moving everything in there to this file. As such, common.txt
more accurately reflects the purpose of this file.
There were many packages that end up being installed via dependency
chains, that were not themselves listed in the requirements files. To
ensure determinism with pip (and to prevent errors with peep, since it
uses --no-deps by default), all packages must be listed explicitly.
I've avoided adding any more packages to checked-in.txt since we will
soon be deleting the vendor directory, so it seems silly to pollute it
further. compiled.txt is now rather unfortunately named, since it lists
packages that are pure and could have been in vendor/.
Versions have been set to match those currently used in production, or
in the case of blessings (which is not installed in production, we're
just lucky our use of mozlog does not hit the import & so haven't seen
the error), I've just set it to the latest available version.
Using git+git means cloning the repo, trying to determine if the ref
specified is a tag or revision or branch etc. Instead Github provides
direct archive zips that are much faster when using pip install.
For changes in compiled.txt, the version matches that installed globally
in production. For those in checked-in.txt I've used the version in
vendor/ which is actually different from that in production's global
site-packages, but is what we're actually using, since vendor/ is
earlier in the Python path.
flake8 is pyflakes+pep8. In a later PR I'll add a mention of it to the
docs - particularly how to set it up as a local git commit hook, but for
now I'm just keen to not regress the passing flake8 run. We may also
need to further tweak the ignore settings in setup.cfg if we find
certain warning types to be too annoying.
To pick up the version number bump. This doesn't change the contents of
vendor/datasource/ so in theory shouldn't be necessary. However prod
pip installs the requirements in pure.txt when it shouldn't, and the
vendor directory is later in python.path than site-packages, so we end
up using the version installed globally. Unfortunately some of the nodes
have an older version of datasource installed, but without the version
bump it's hard to tell which.
William Lachance
Cameron Dawson
Ed Morley
Mauro Doglio
mdoglio
Jonathan Eads
vagrant