Competing static site generators integrate the functionality of regenerating
content and serving it into their main executable. In pelican this
functionality used to be in an external script `develop_server.sh` which
resides in the blog base directory. This has the disadvantage that changes in
pelican can break the `develop_server.sh` scripts which will not automatically
be upgraded together with pelican by package managers. Thus, pelican should
integrate this functionality into its main executable.
To this end, this commit removes `develop_server.sh` and adds three command
line options to the pelican executable:
* `-l/--listen` starts the HTTP server (`-s/--serve` was already taken)
* `-p/--port` specifies the port to listen at
* `-b/--bind` specifies the IP to bind to
`--listen` and `--autoreload` can be used together to achieve the same
effect that other static site generators offer: Serve files via HTTP
while at the same time auto-generating the content.
Since the `develop_server.sh` script was removed, pelican-quickstart looses the
`develop` option.
Since the `develop_server.sh` script was removed, the Makefile looses the
`stopserver` target and the `devserver` target is replaced by running `pelican
-l` in the foreground.
Since pelican now offers the `--listen` option, the fabfile uses that instead
of starting the socketserver itself.
- Use the jinja2 templating language for Makefile, fabfile,
pelicanconf, publishconf, and develop-server.sh
- Add logic in pelican_quickstart.py
- Let jinja2 handle opening and reading template files
- Remove thus unused functions for string.Template
This allows the user to set PY and/or PELICAN environment variable
overrides, which will be respected by the Makefile and devserver.sh.
If, for example, the default Python on your system were Python 3 and
you wanted to run Make with Python 2, using bash you could run
`PY=python2 make`. Refs #915.
Previously pelican-quickstart would assume that the site it created for GitHub
Pages should be published to the gh-pages branch. This is correct for project
pages, but not correct for personal pages. Personal pages, which live in a
user's special username.github.io repository, are instead deployed to the
master branch. This means that if you did pelican-quickstart and tried to
publish your new personal site with make github you'd see nothing (or whatever
old pages site you had floating around in master).
ghp-import already supports publishing to different branches, so publishing
to the correct branch is just a matter of correct configuration and updating
the Makefile to pass the branch along to ghp-import. pelican-quickstart now
asks if the user wants to publish to GitHub Pages, and if so, asks if this
is a personal page and chooses the correct branch appropriately. I preferred
this approach to prompting for an arbitrary branch because I felt that
choosing the branch would feel more intimidating to someone using
pelican-quickstart for the first time.
This essentially ports changes I made to my personal pages site at
jculpon@82cae477a9e8712b90654f6432464369ebcc7ae5
This commit adds optional fabfile.py generation during the
pelican-quickstart process. Reasons include:
* "make" is cumbersome to install on Windows
* Fabric runs in any Python environment
* fabfile is just Python and thus more flexible and extensible
This is an initial implementation and does not currently provide as many
upload options as its Makefile counterpart.
Refs #584.
This script and the small changes to quick start's makefile make for easily launching and killing of pelican --debug --autoreload and SimpleHTTPServer.
This is extra useful for working on templates.
Certain configuration options are more useful in production than they
are in development. Some examples might be absolute URLs, external
analytics service identifiers, Disqus comments, etc. This version of the
quickstart script creates two configuration files: one for development
and the other for use when publishing. In addition, the related docs
have been expanded considerably. Last but not least, the quickstart
script will now detect whether there is a project folder associated with
the currently active virtualenv (if any) and use it by default.
