Summary:
Our Arch package is broken because it doesn't install asyncio and
pathlib. These shouldn't *need* to be installed, because Arch is running
Python 3.4, but the executable script that setup.py generates is getting
confused. It seems like the right thing to do is to make sure these
extra dependencies never make it into our `install_requires` list in
Python 3.4. I *think* the fact that our setup.py ends up in the source
distribution means that `pip install peru` will still do the right thing
for Python 3.3.
Test Plan: Tested `pip install .` in a python3.3 virtualenv.
Reviewers: sean
Reviewed By: sean
Differential Revision: https://phabricator.buildinspace.com/D151
Summary:
Remove the third-party/ directory and no longer rely on copies of dependencies
in the repo. When needed, fetch dependencies normally. This can usually be
accomplished via `pip install -r requirements.txt` or `pip install -r
requirements-dev.txt`.
Even though `peru.yaml` is gone, `.peru/` is still in `.gitignore`, because the
tests check for untracked files and will detect `.peru/` as an error.
Test Plan: Successfully ran tests locally and via Travis CI.
Reviewers: jacko
Reviewed By: jacko
Differential Revision: https://phabricator.buildinspace.com/D145
Summary:
This was the recommendation of
https://packaging.python.org/en/latest/distributing.html, but I unwisely
ignored it back when I wrote our setup.py. It turns out that getting a
launcher script to work properly on Windows is tricky. The
`entry_points` field generates a platform-appropriate launcher script at
install time, so we get Windows for free.
Previously our launcher script checked the version of Python and printed
a helpful error if it was too low. Because our main.py has `yield from`
syntax in it, printing such an error message isn't possible; we'll crash
with a syntax error first. We could create another file within the
modile (or maybe an __init__.py) to support this, but for now I'm just
dropping the feature.
Test Plan:
Manually played with peru.sh to make sure it still works. Ran
`pip install .` to check that the generated script works. Also tested
that on my Windows VM, and it works great. (It generates an exe file, in
fact.)
Reviewers: sean
Differential Revision: https://phabricator.buildinspace.com/D135
Summary:
Create a simple setup.py file from the instructions at
https://packaging.python.org/en/latest/distributing.html. The
`package_data` field doesn't seem to like directories, so we need to
walk the paths under `./peru/resources` to include everything.
Right now we're not including anything under third_party. Instead we
pull those in as dependencies from PyPI. Not sure if this is what we'll
do in the long term, but it's nice that it works.
Test Plan:
Ran `python3 setup.py install --user` and confirmed that peru works.
Then `cd tests; python3 -m unittest` to confirm that tests pass against
the installed version.
Reviewers: sean
Reviewed By: sean
Differential Revision: https://phabricator.buildinspace.com/D125
Jack O'Connor