# website-pictures2

**The World's Worst Way To Do This**

## What

### What I Did Before

My website is not hosted locally and my server is perpetually
running out of space (actually, this is not true anymore???)

`website-pictures1` used GitHub to host compressed and encrypted JPGs
that would then be cloned on a cloud server (OCI free tier :pray:)
and built into a static site.
This model was based around assuming the following:
1. I don't want people to see these pictures without fist being authorized
    - i.e. HTTP Basic Auth
2. I do not trust GitHub to hold my pictures in an unencrypted format (follows from 1)
3. `Ramiel` was the sole source of truth for building the picture directories and
4. the cloud server was responsible for building the static pages.

### That Was Bad, Actually

The previous model was lame because:
1. If I do not have access to `Ramiel`, I can't do anything
    - it was all symlinks oh my god
2. it was literally shell scripts
    - ok, no diss to shell scripts, these in particular were actually super manageable.
    - the problem is that expanding them to do more sucks bigly
3. key point: I never added more pictures because it was a Huge Pain

### What I Will Be Doing Now

I've just confirmed that `bigrack` has more than enough space to do the following:
1. Store pictures compressed, locally
    - you can just add to a 7z archive whenever, so uncompressed images need not exist more than transiently
2. Build a static page, locally
    - big if true: imagine being able to debug without doing a full rebuild on your server
3. Deploy the static page to `shrimplover`
    - no like seriously why do I pick hostnames like this

## How

python or something idk


## Usage

### Archive management

`python main.py archive add -a PATH_TO_ARCHIVE -p FOLDER_NAME_ON_WEBSITE [Files to add]`

### Deployment

`python main.py deploy -a PATH_TO_ARCHIVE SSH_HOST PATH_ON_REMOTE_TO_PICTURES_DIR`