mattjmcnaughton / sdep Goto Github PK

Instead of hardcoding the version in setup.py, we should dynamically read it from sdep/__init__.py.

• Document using sdep to deploy a blog.
• Stop referencing Route53 and Cloudfront and instead give directions for working with whatever domain registrar and Cloudflare.

Problem

Currently, the placement of different users .sdeprc files could impact the results from the test suite. Additionally, we avoided certain tests, or wrote them more generally, so as to avoid instances in which the local file system could effect test output. For example, the test for whether Config#locate_config_file finds ~/.sdeprc. Whether the user has an .sdeprc in the directory from which they are running these tests effects the result of this test.

Solution

As such, all file system tests should occur within a temporary scratch directory. We can mock calls to os.getcwd() and os.path.expanduser("~") so they return this mocked temp directory. We can then delete the temp directory after we are done running each test.

Right now, there is a decent amount of overlap in the helper functions we define in our different subclasses of unittest.TestCase. However, we should wait until we spin out config.py into its on class.

These utility functions would do things like handle the creation of temporary files and directories, etc.

Because of the strength of moto and boto for communicating/mocking communicating with AWS, I'm thinking it makes the most sense to write sdep in python. As such, I'll need to do the steps below for creating the application's skeleton. When in doubt, I emulate flask.

• Define directory layout (i.e. where to place tests).
• Configure travis.yml.
• Write Makefile for building/pushing the package to pip.
• Create Dockerfile for development environment and add common development tasks to the Makefile (i.e. test, lint).

I messed up with semver on this project (starting with 0.10, instead of 0.1.0). So at some point, I'll just start over at 0.1.0. I'll need to update the dependencies for sites using sdep (just my sites) as well as delete the old tags and pip packages.

Write good docs, with the accompanying code and tests, for the command line interface and where to specify configuration options. This process will allow us to determine the public api, and should also give a good sense of the next steps re coding.

• Create the next issues tasks during this step.

It would be cool if in addition to installing sdep through pip, it was also possible to install it as a .deb package. Perhaps we could use pypi to do the packaging.

S3 buckets allow the option of logging as seen in this tutorial. Make an optional configuration flag which allows the user to turn on logging for their static site. We can use this boto call. It will also require creating a bucket in which we will store our logs.

Add and test the main actions which can be taken on the static site. The Sdep class contains these actions.

• create
• update

This works locally, but is blank in production. http://sdep.readthedocs.io/en/latest/api.html#

Currently we upload the entire site directory to s3 both during the create and update actions. S3 will just overwrite any files that are already there. If possible, we should only upload files that have changed during update. We could perform this selective upload either through checking the last modified times on the files, or checking hashes of files, or maybe something else.

This class is responsible for reading configuration either from a file or environment variables and making it accessible to an instance of the Sdep class.

When telling AWS to have our bucket perform like a website, with this boto call, we have the option of specifying which suffix will represent an index file (currently index.html) and the file to display when there is an error (currently 404.html). Make both of these configurable options with sensible defaults.

Add the CHANGELOG and think of a better way to schedule version updates.

Make AWS region an optional configuration flag, with a sensible default (i.e. us-east-1). This may not be super important if we're using Amazon CloudFront to serve the content from as close to the user as possible, but it seems like good practice regardless.

If we want to be able to access our site both from sdep-example.com and www.sdep-example.com, then we need to create S3 buckets for both, as indicated in this AWS tutorial.

This will just require small modifications to the create action to create both buckets, and perhaps modifications to the update action so we are updating the files in both buckets.

All of the configuration handling for sdep is non-specific to this given use-case (except for some constants which could easily be passed as configuration values). Given our configuration handling is stand-alone and reusable, we should package the configuration handling into a stand-alone package which we will host on pip. We should not spin out until configuration is relatively stable, otherwise it will be too much of a pain to have to update the pip package every time we want to make a change.

Use Sphinx and Read the Docs for setting up documentation.

Currently, the directory we upload to S3 to serve as our static site is configurable through Config as SITE_DIR. However, currently we upload all the files in that directory. We should include a configuration option with files/dirs to ignore, so that they can specify files to not be uploaded.

There's a Makefile task that specifies a lot of what has to be done.

It should be possible to run $ sdep create from the terminal, as opposed to having to import the module and call it from a python file.