Initial checkin

This commit is contained in:
Aldo Cortesi 2015-08-16 12:39:06 +12:00
commit 20d89cd34f
7 changed files with 191 additions and 0 deletions

5
.env Normal file
View File

@ -0,0 +1,5 @@
DIR="${0%/*}"
if [ -z "$VIRTUAL_ENV" ] && [ -f "$DIR/../venv.mitmproxy/bin/activate" ]; then
echo "Activating mitmproxy virtualenv..."
source "$DIR/../venv.mitmproxy/bin/activate"
fi

15
.gitignore vendored Normal file
View File

@ -0,0 +1,15 @@
.DS_Store
MANIFEST
/build
/dist
/tmp
/doc
/venv
/libmproxy/gui
/release/build
*.py[cdo]
*.swp
*.swo
/venv
/release

10
README Normal file
View File

@ -0,0 +1,10 @@
General build and release utilities for the mitmproxy, netlib and pathod
projects. These tools assume a directory structure with all repositories at the
same level, for example:
/src/
./mitmproxy
./netlib
./pathod
./release

66
osx-binaries Executable file
View File

@ -0,0 +1,66 @@
#!/bin/sh
# Quick and dangerous script for building OSX binaries.
# At the moment, pyinstaller has no support for entry points, except for this
# hideous hack on the wiki:
# https://github.com/pyinstaller/pyinstaller/wiki/Recipe-Setuptools-Entry-Point
# Once this is fixed, we can ditch the redundant command scripts.
VENV=../venv.mitmproxy
PYINST_CMD="$VENV/bin/pyinstaller -F --clean"
TMPDIR=./tmp
CACHE="~/Library/Application Support/pyinstaller"
if [ ! -d $VENV ]
then
echo "Failed: set up a dev environment as described in the README"
echo "and run from the top-level mitmproxy directory."
exit
fi
source $VENV/bin/activate
if [ ! -f $VENV/bin/pyinstaller ]
then
echo "Installing pyinstaller..."
$VENV/bin/pip install \
--force-reinstall \
--upgrade \
https://github.com/pyinstaller/pyinstaller/archive/develop.zip
$VENV/bin/pip install --upgrade macholib
fi
# readline.so is actually a symlink to a Python file, which breaks PyInstaller
# (and readline itself). Why? Who knows. Re-address this when this stupidity
# ceases to be.
echo "Removing broken readline..."
rm -f $VENV/lib/python2.7/readline.so
echo "Clearing caches..."
rm -f dist/*
rm -rf $TMPDIR
rm -rf $CACHE
$PYINST_CMD ./release/mitmdump.spec
echo "Running mitmdump..."
./dist/mitmdump --version || exit 1
$PYINST_CMD ./release/mitmproxy.spec
echo "Running mitmproxy..."
./dist/mitmproxy --version || exit 1
$PYINST_CMD ./release/mitmweb.spec
echo "Running mitmweb..."
./dist/mitmweb --version || exit 1
DST=osx-mitmproxy-`./dist/mitmdump --shortversion 2>&1`
mkdir -p $TMPDIR/$DST
cp ./dist/mitmproxy $TMPDIR/$DST
cp ./dist/mitmdump $TMPDIR/$DST
cshape ./doc-src $TMPDIR/$DST/doc
cd $TMPDIR
tar -czvf $DST.tar.gz $DST

55
release-checklist.md Normal file
View File

@ -0,0 +1,55 @@
# Release Checklist
## Test
- Create the source distributions, make sure the output is sensible:
`./release/build.py release`
All source distributions can be found in `./dist`.
- Test the source distributions:
`./release/build.py test`
This creates a new virtualenv in `../venv.mitmproxy-release` and installs the distributions from `./dist` into it.
## Release
- Verify that repositories are in a clean state:
`./release/build.py git status`
- Update the version number in `version.py` for all projects:
`./release/build.py set-version 0.13`
- Ensure that the website style assets have been compiled for production, and synced to the docs.
- Render the docs, update CONTRIBUTORS file:
`./release/build.py docs contributors`
- Make version bump commit for all projects, tag and push it:
`./release/build.py git commit -am "bump version"`
`./release/build.py git tag v0.13`
`./release/build.py git push --tags`
- Recreate the source distributions with updated version information:
`./release/build.py sdist`
- Build the OSX binaries
- Follow instructions in osx-binaries
- Move to download dir:
`mv ./tmp/osx-mitmproxy-VERSION.tar.gz ~/mitmproxy/www.mitmproxy.org/src/download`
- Move all source distributions from `./dist` to the server:
`mv ./dist/* ~/mitmproxy/www.mitmproxy.org/src/download`
- Upload distributions in `./dist` to PyPI:
`./release/build.py upload`
You can test with [testpypi.python.org](https://testpypi.python.org/pypi) by passing `--repository test`.
([more info](https://tom-christie.github.io/articles/pypi/))
- Now bump the version number to be ready for the next cycle:
**TODO**: We just shipped 0.12 - do we bump to 0.12.1 or 0.13 now?
We should probably just leave it as-is and only bump once we actually do the next release.
Also, we need a release policy. I propose the following:
- By default, every release is a new minor (`0.x`) release and it will be pushed for all three projects.
- Only if an emergency bugfix is needed, we push a new `0.x.y` bugfix release for a single project.
This matches with what we do in `setup.py`: `"netlib>=%s, <%s" % (version.MINORVERSION, version.NEXT_MINORVERSION)`

2
requirements.txt Normal file
View File

@ -0,0 +1,2 @@
click>=4.1
twine>=1.5.0

38
test-release Executable file
View File

@ -0,0 +1,38 @@
#!/bin/bash
MITMPROXY_DIR=~/mitmproxy/mitmproxy
NETLIB_DIR=~/mitmproxy/netlib
PATHOD_DIR=~/mitmproxy/pathod
DST=/tmp/mitmproxy_release
rm -rf $DST
mkdir -p $DST
cd $NETLIB_DIR
echo "Creating netlib source distribution..."
python ./setup.py -q sdist --dist-dir $DST
echo "Creating mitmproxy source distribution..."
cd $MITMPROXY_DIR
python ./setup.py -q sdist --dist-dir $DST
echo "Creating pathod source distribution..."
cd $PATHOD_DIR
python ./setup.py -q sdist --dist-dir $DST
echo "Creating virtualenv for test install..."
virtualenv -q $DST/venv
cd $DST
echo "Installing netlib..."
./venv/bin/pip -q install --download-cache ~/.pipcache ./netlib*
echo "Installing pathod..."
./venv/bin/pip -q install --download-cache ~/.pipcache ./pathod*
echo "Installing mitmproxy..."
./venv/bin/pip -q install --download-cache ~/.pipcache ./mitmproxy*
echo "Running binaries..."
./venv/bin/mitmproxy --version
./venv/bin/mitmdump --version
./venv/bin/pathod --version
./venv/bin/pathoc --version