The main reason is so the constants defined in the status-codes
packages can use it. I've put the (HTTP) status codes in their own
package because they are a self-contained thing. I find it easier to
work with them this way.
nera is responsible for the database stuff which is not part of
Caveman2. The status-codes package is a list of constants representing
the various HTTP status codes -- with an explanation of what they are for.
I was having trouble trying to get hermetic and mito-auth to work
together. I decided to just use normal mito and leave hermetic to the
authentication/authorisation stuff.
There was snippets of code in the code I liked. I'm going to keep it
around for a bit to see if I can work some of it in to the new
code. I'm most interested in the deployment code.
I tried it and I find it easier to work with Caveman2. I didn't
realise this templating program is built around Hunchentoot -- whereas
Caveman2 builds on top of. So, I'm moving the code to back to Caveman2
-- where I originally started. It looks like a waste of time but the
knowledge of having a look at the other stuff has been helpful.
This script adds a user to the database based on it's inputs (prompted
for the person running the script). The intention is to add a user to
the database easier (especially on a live production server with just
the CLI).
https://github.com/vindarel/cl-cookieweb (for GitHub Repo. and
instructions).
The reason for using this is because it makes it easier to run the
website as a standalone thing. You don't need to link it up to
Quicklisp's /local-project directory. It has scripts to help you build
the binaries and to run the website (as a standalone) thing. I, also,
hadn't use this 'cookie cutter' program before so it's a good time to
get my feet wet.
The admin. backend for Django isn't as easy to get to where I want it,
compared to Caveman2. The trade-off is Common Lisp isn't a mainstream
language so it does reduce the level of ease other might have when/if
they join the project.
I'm going to try this with Python and Django first. Because it's not
my personal project, it might be better to use a language which is
more mainstream. It should reduce the 'Bus Factor'.
Craig Oates