Skip to content
This repository has been archived by the owner on Sep 17, 2024. It is now read-only.

Static site generator #36

Open
wants to merge 13 commits into
base: master
Choose a base branch
from
Open

Static site generator #36

wants to merge 13 commits into from

Conversation

cuducos
Copy link
Collaborator

@cuducos cuducos commented Jun 18, 2019

This PR focuses on simplifying the production stack needed to deploy this web site: instead of a Python back-end and Redis, the proposal is to switch to a static site generator. Code reviewing this PR could be troublesome because there's a lot of changes, but the summary is:

  1. Drop stuff that makes no sense in a static site generator:
  2. Minor improvements:
  3. Implementing the static generator (ad35ce2)

If this looks like a good approach, one it's on master I can try to set it up on Netlify or GitHub pages, for example.

When code reviewing I suggest two (non-exclusive) strategies: first is to review commit by commit to focus on smaller sets of changes; second, to follow the instructions on the updated version of the README.md.

cuducos added 9 commits June 18, 2019 13:54
This might sound counterintuitive but this commit is part of a
overarching change in this project, aiming at transforming it in a
static generator instead of a conventional web app.
This might sound counterintuitive but this commit is part of a
overarching change in this project, aiming at transforming it in a
static generator instead of a conventional web app.
This might sound counterintuitive but this commit is part of a
overarching change in this project, aiming at transforming it in a
static generator instead of a conventional web app.
This might sound counterintuitive but this commit is part of a
overarching change in this project, aiming at transforming it in a
static generator instead of a conventional web app.
@cuducos cuducos force-pushed the static-site-generator branch 4 times, most recently from 9d94189 to 530bd71 Compare June 19, 2019 03:05
@cuducos
Copy link
Collaborator Author

cuducos commented Jun 19, 2019

Update

With f12bd71 we're already using GitHub Pages. I've updated the DNS and http://www.vitimasdaintolerancia.org/ is already being served by GitHub.

Disclaimer

First I tried @netlify, but as they do not support Python 3.7 and as we use dataclasses (only available — natively — in Python 3.7) and as they do not support Pipenv, I decided to give GitHub Pages a try. Although I was unable to remove @netlify checks from this repository. What I've try:

  1. deleted the site on Netlify
  2. removed webhooks from this repository here on GitHub
  3. restricted access to Netlify on this repository (GitHub organization settings)
  4. changed the HEAD and forced a git push to trigger a new build

But stills… Netlify is running FIVE checks on this pull request. Any ideas how to remove these checks as we're not using @netlify anymore?

Now every check is gone, including Travis and Code Climate. Aff.

Todo

I think that if this PR is approved and merged we can close:

  1. Update to Python 3.7.1 #35: Python was already updated here (to a newer version than in this other PR)
  2. Improvement: if the Debug true disable the verify ssl in fetch content, That form is better to run local, I think :) #27: as SSL would not be a matter for this repository anymore

@cuducos cuducos force-pushed the static-site-generator branch 2 times, most recently from aa22e68 to f12bd71 Compare June 19, 2019 11:30
@cuducos cuducos force-pushed the static-site-generator branch from c9c848e to a9b9691 Compare June 19, 2019 11:50
@sergiomario
Copy link
Collaborator

@cuducos I've checked the static content generation template and it looks okay. But, I have a question, you implemented static generation in Flask because the framework API is similar to Sanic, right?

I asked because I see simpler implementations with pelican, for example. But I think you should have chosen to keep an architecture similar to that drawn with Sanic.

@cuducos
Copy link
Collaborator Author

cuducos commented Jun 21, 2019

Good point. I think there is a two-fold advantage in using this strategy (i.e. Flask + Freeze):

  • It's the simplest implementation at this point: as the web app was written in Sanic (which is basically an asyncio fork of Flask), it was easy to transform it in a static site generator without bordering about adapting the whole architecture to Pelican's architecture;
  • It's the simplest way to allow us to revert this back to a web app: if in the future we want to have it as a web app again (let's say, implement a CMS, dynamic search and filters or whatever), the web app is ready and we'd just need a Procfile to spin it up at Heroku again

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants