karenc

#!/usr/bin/env python3
from datetime import datetime
import glob
import os
import pathlib
import re
import subprocess
import sys
import tempfile
from urllib.parse import urlparse, urljoin

karenc

#!/var/cnx/venvs/archive/bin/python
"""
This script attempts to dump a book from the server and load it into a
development database.

1. You need to download this script onto the server, e.g. staging08.cnx.org,
   that runs archive.

2. Use `./dump_book.py dump_book caa57dab-41c7-455e-bd6f-f443cda5519c@19.3` to
   dump the prealgebra book.

wbsch

#!/usr/bin/env python
#
# Adds the ability to add / modify tasks using a "blocks:" attribute,
# the opposite of "depends:".
#
# This script acts as an on-modify, on-add and on-launch hook at the same time.
#
### SETUP
# Save this file as
#   ~/.task/hooks/on-modify.blocks_attr.py

reedstrm

Recommendation for code versioning for OpenStax (née Connexions) code.

1. use git tags, of the form: v[numeric-version]
2. we tag complete (or at least, stable) features, for roll out to demo, qa, sprint and production a. exception: dev will roll from HEAD of master b. tags will be on the master branch, post merge (if other patchfix tags are needed, devops will tag on staging/production) c. Tags are done by developers, primarily, and include "in development" extra version info (see below)
   1. git describe at minimum
   2. bump versions as needed
3. devops will finalize tags (and versions) at rollout

inklesspen

(This gist is pretty old; I've written up my current approach to the Pyramid integration on this blog post, but that blog post doesn't go into the transactional management, so you may still find this useful.)

Fast and flexible unit tests with live Postgres databases and fixtures

I've created a Pyramid scaffold which integrates Alembic, a migration tool, with the standard SQLAlchemy scaffold. (It also configures the Mako template system, because I prefer Mako.)

I am also using PostgreSQL for my database. PostgreSQL supports nested transactions. This means I can setup the tables at the beginning of the test session, then start a transaction before each test happens and roll it back after the test; in turn, this means my tests operate in the same environment I expect to use in production, but they are also fast.

I based my approach on [sontek's blog post](http://sontek.net/blog/