The current regex assumes that pylibmc appears at the beginning of a line
(whitespace only precedes it), which is a fair assumption in a single 'flat'
requirements.txt file. However, if you are using nested requirements then
this is not the case - your pylibmc may exist in a sub-directory. This is
very similar to the way in which mercurial is installed if "hg+" is found
in the requirements file (see the /bin/compile script). By insisting that
pylibmc appear at the beginning of the file, it's impossible to fool the
compilation into installing libmemcached (as this script does) by simply
putting the phrase into a comment, which is what you *can* do with 'hg+'.
I've updated the regex to remove the beginning of line restriction. This
means that you can add a comment to a top-level requirements.txt that
will trigger the install, without having to functionally alter your
nested requirements.
e.g. top-level requirements.txt:
# fake comment to trigger pylibmc script
# fake comment to trigger hg+ install
-r requirements/production.txt
In `bin/steps/collectstatic` the unbuffered output in `indent` is subverted
by calling `sed` first:
```shell
python $MANAGE_FILE collectstatic --noinput 2>&1 | sed '/^Copying/d;/^$/d;/^ /d' | indent
```
This commit fixes this by making `sed` itself unbuffered rather than
putting that logic in the `indent` function.
The compile script is run with the root of the git repo of the project
being pushed as the working directory.
$BIN_DIR is pointing to the bin directory of the buildpack which is not
where you would want to put the pre and post compile hooks.
Changing back to the old convention of looking for the hooks from the
bin directory at the root of the project.