Release version 1.0.0 and set up deployments to PyPi from master

[jeancochrane]

Overview

This PR bumps Ashlar to version 1.0.0, updates the package metadata with more details, and sets up Travis to deploy to PyPi from commits to the master branch.

Checklist

• PR has a descriptive enough title to be useful in changelogs

Notes

Once this PR gets approved, I'll squash and merge and then do the following things to wrap up packaging:

• Merge develop into master to cut the 1.0.0 release to PyPi
• Tag this squashed commit with v1.0.0
• Continue developing on develop

Testing Instructions

• Travis will run unit tests to confirm that the package is being installed correctly.
• When this PR gets pulled into develop, it will deploy the package to the PyPi test instance at https://test.pypi.org/project/ashlar/ to confirm that the package is being published properly. In a subsequent PR, I'll remove this deployment directive from Travis. Unfortunately, there doesn't seem to be a reliable way to test PyPi package CI from a PR, since encrypted variables are not available from pull requests in Travis; if you can think of a better way to test this, I'm all ears.

Closes azavea/grout-2018-fellowship#23.

[ddohler]

This looks good to me! As far as the deployment, is there any harm in continuing to deploy to test.pypi.org whenever there's a merge to develop? That seems like it would be a useful test to run on a continuing basis.

For the encrypted variables, I think that you shouldn't have any problem accessing them from this PR since they're coming from the same repository, according to the docs:

Travis CI makes encrypted variables and data available only to pull requests coming from the same repository. These are considered trustworthy, as only members with write access to the repository can send them.
https://docs.travis-ci.com/user/pull-requests/

Did you try it and run into issues?

Also, our standard practice is to enable both branch and pull request builds: https://docs.travis-ci.com/user/pull-requests/#%E2%80%98Double-builds%E2%80%99-on-pull-requests Can you make sure both of those are enabled?

Last thing, if you had to set up any accounts in order to get this working, can you make sure that the passwords are in LastPass?

[jeancochrane]

Thanks for the comments @ddohler! Replying inline:

As far as the deployment, is there any harm in continuing to deploy to test.pypi.org whenever there's a merge to develop? That seems like it would be a useful test to run on a continuing basis.

Good point! It'd be nice to continually test published packages on test.pypi.org. My understanding is that as long we remove the skip_existing flag in .travis.yml, it should just continually publish the builds.

For the encrypted variables, I think that you shouldn't have any problem accessing them from this PR since they're coming from the same repository, according to the docs

I didn't know encrypted environmental variables were available in PRs originating within the source repo, that makes a lot more sense. In this case the deployment seems not to be working, not because the environment variables aren't decrypted but because of some specific rule around pull requests, which raises the warning:

Skipping a deployment with the pypi provider because the current build is a pull request.

I'm not sure yet if this is PyPi specific, or global to travis deploy directives. Preliminary research seems to imply that it's possible to deploy from pull requests in general, so I'm thinking it may be PyPi-specific. I'll keep digging.

Also, our standard practice is to enable both branch and pull request builds.

Yep, both are enabled in this case. It isn't pushing branch builds because I'm restricting it to build from deploy and master; I can loosen that up to all branches if it's more in line with usual practice.

Last thing, if you had to set up any accounts in order to get this working, can you make sure that the passwords are in LastPass?

The credentials were all already in LastPass, so we're good to go!

[ddohler]

Yep, we usually end up with two builds for each branch, one for the branch itself and the other for the PR. Everything else sounds good!