Two fixes
I pulled two commits out of !57 since it would be good to have them included, and specifically the `buildToolsVersion` issue was just discussed.
The current state of the `buildToolsVersion` replacement is not good. It will replace this:
```
buildToolsVersion '21.0.1'
```
with this:
```
buildToolsVersion = '21.0.1'
```
That is incorrect, since the first form is more like a function call than a variable assignment. So most likely that is causing the `buildToolsVersion` to be unset. The commit here includes a fix that works for both the rare, non-standard variable assignment way, i.e. `buildToolsVersion = '21.0.1'` as well as the standard way: `buildToolsVersion '21.0.1'`. It also includes tests for both cases.
See merge request !65
This addresses the discussion in !64https://gitlab.com/fdroid/fdroidserver/merge_requests/64
Sometimes, buildToolsVersion is a kind of gradle macro call, and other
times it is a variable assignment. This regsub pattern now handles both of
those cases.
Google code is dead and going read-only. import is just a helper program, and
we don't want to help people add apps from google code anymore. Apps should
move to other hosting sites.
Fix gradle adaptation for custom buildToolsVersion configurations
I have ```build_tools = "22.0.1"``` configured in my config.py, however a recent fdroidserver update broke this. This PR fixes it for me.
See merge request !64
final 0.4.0 fixes
Because `setup.py` is broken because `MANIFEST.in` is still pointing to `README` and not `README.md`, the 0.4.0 tag needs to be deleted. This merge requests fixes that and two other minor issues. This has passed multiple runs of the test suite, both on my machine and the jenkins box.
See merge request !61
let setuptools determine the base install path on OSX
This is the last commit from me before the 0.4.0 release. Its ready to go!
A gentle reminder:
* sign the tag: `git tag -s 0.4.0 -m "tagging release 0.4.0"`
* release tags are `0.4.0` format, not `v0.4.0`
* change the version in `setup.py` to match the tag exactly, char by char
Then I'll post the update to pypi.python.org
See merge request !59
Instead of trying to guess which absolute path and .egg name
everything will be installed into, just use a relative path and the
setup process will do the right thing (so far, at least).
BSD/OSX porting and tests
This makes `fdroid init` and `fdroid update` work on BSD/OSX and maybe Cygwin also (I didn't test Cygwin). It also makes the install process more tolerant, like not requiring `python-magic` to run, while using it if its available.
Some fixes and additional tests are also included. The commit messages have more info.
See merge request !56
Since `python setup.py sdist` provides the actual tarball that will be
installed via `easy_install`, `pip install`, etc. it should also be tested.
The existing `pip install -e $WORKSPACE` tests the .egg-link install format
If you run `python setup.py install` from the git repo, then it will be
installed using the .egg-link format, which just points to the git repo.
`fdroid init` needs to handle that when looking for example files to copy.
