| FROM python:3.5 | |
| # Yes, all of the below is really to get GDAL running in a container. Your eyes do not deceive you. | |
| RUN apt-get update -y | |
| RUN apt-get install -y g++ \ | |
| wget \ | |
| libcurl4-openssl-dev \ | |
| build-essential \ | |
| libpq-dev \ | |
| ogdi-bin \ |
| #!/usr/bin/env python | |
| """ | |
| Decorator for fluent interface classes. | |
| """ | |
| import functools | |
| import inspect | |
| def chained(method): | |
| """Method decorator to allow chaining.""" |
Source: http://www.jejik.com/articles/2007/02/a_simple_unix_linux_daemon_in_python/
by Sander Marechal
I've written a simple Python class for creating daemons on unix/linux systems. It was pieced together for various other examples, mostly corrections to various Python Cookbook articles and a couple of examples posted to the Python mailing lists. It has support for a pidfile to keep track of the process. I hope it's useful to someone.
There are many Git workflows out there, I heavily suggest also reading the atlassian.com [Git Workflow][article] article as there is more detail then presented here.
The two prevailing workflows are [Gitflow][gitflow] and [feature branches][feature]. IMHO, being more of a subscriber to continuous integration, I feel that the feature branch workflow is better suited.
When using Bash in the command line, it leaves a bit to be desired when it comes to awareness of state. I would suggest following these instructions on [setting up GIT Bash autocompletion][git-auto].
When working with a centralized workflow the concepts are simple, master represented the official history and is always deployable. With each now scope of work, aka feature, the developer is to create a new branch. For clarity, make sure to use descriptive names like transaction-fail-message or github-oauth for your branches.
create different ssh key according the article Mac Set-Up Git
$ ssh-keygen -t rsa -C "[email protected]"