pyenv でインストールされたpipを含めてupgradeする方法

pyenv の python をバージョンアップしたい

pyenv でインストールしたpython をバージョンアップして、pipをmigrate したい・

pyenv はバージョン毎にpip環境が作られるから、pyenv でglobal をアップグレードすると、使ってたpipのパッケージが移動されずに真っ白な環境になってしまう。

そこで pipのパッケージをmigrationしたいと思った

pyenv-pip-migrate で一括アップグレード

pyenv-pip-migrate という モジュールがあって、コレを使えばマルっとバージョンアップしてくれることがわかった。

pyenv-pip-migrateのインストール

brew install pyenv-pip-migrate

これをインストールしたら準備完了

pyenv でバージョンアップする

現状が次のバージョンなので、これを3.6.4にする。

$ pyenv version
3.6.0 (set by /Users/takuya/.pyenv/version)

バージョンアップしよう

現状は 3.6.0 だったので、これをアップグレードしてpython の pip モジュールもアップグレードしていきます。

準備

brew install pyenv-pip-migrate

python の 最新版(2018-02-17現在)をいれる。

$ pyenv install 3.6.4
Installed Python-3.6.4 to /Users/takuya/.pyenv/versions/3.6.4

version 3.6.4 がインストールされました。

$ pyenv versions
  system
* 3.6.0 (set by /Users/takuya/.pyenv/version)
  3.6.4

pip を最新版バージョンに併せて置き換える。

python の一括が終わったら、pipを入れていきます。

今回は 3.6.0→3.6.4 にあげていきます。

$ pyenv migrate 3.6.0 3.6.4

これで、pip のインストールが始まる。

仕上げ

最後に仕上げです。新バージョンにglobalを変える

$ pyenv global 3.6.4

これで問題なく環境を移行できました。楽ちん！

せっかちな人向け

OLD_VERSION=$(pyenv version global version | sed 's/\s.*$//')
NEW_VERSION=$(pyenv install --list  | \sed "s/\s*//"  | \grep -P '^\d\.\d\.\d$' | \sort -nr | \head -n 1)
brew install pyenv-pip-migrate
pyenv install $NEW_VERSION
pyenv migrate $OLD_VERSION $NEW_VERSION
pyenv global $NEW_VERSION

エラーになったり、移行させるパッケージを選びたいよって人向け

現在のpipの状態は freeze で持っていけるので、それを使うといい

pip freeze > requirements.txt

つまり、古いバージョンの方で freeze して 新しいバージョンで install する。

pyenv global 3.6.7
pip freeze > requirements.txt
## 適当に編集
vim requirements.txt
## バージョンを切り替え
pip global 3.7.0
pip install -r requirements.txt

わざわざ、migration 入れないでいいのは便利。

参考資料

https://github.com/pyenv/pyenv-pip-migrate

python の datetime をUNIX timestamp にする方法

python で int 秒をとる

UNIX Epoch な時間が欲しいなーって思ったときにどうするか int秒のタイムスタンプがあったら嬉しいわけですよね。

#!/usr/bin/env python

import datetime
import time
import pprint

pp = pprint.pprint

a = datetime.datetime.strptime('2017-11-23 15:00', "%Y-%m-%d %H:%M")
pp( a.timestamp() )              # 1511416800.0
pp( time.mktime(a.timetuple()) ) # 1511416800.0
pp( int(a.strftime('%s')) )      # 1511416800

strftime 最強説

これ試して思ったけど、 strftime('%s') 最強じゃね？ 言語に拘らず、時間のフォーマット変換できるじゃん。

strftime を標準実装してない JS とかは除くとして、strftime さえ覚えておけば、かなり使える知識になるね。

IntelliJ IDEA(系）でJSONを美しくする

JSONが１行で記載されてて、めんどくさかった。

JSONを整形したり、フォーマットを整えて閲覧しようとして、ついついプラグインを探していてなぜかソレを使っていたんだけど、落ち着いて考えたら、コードフォーマッターに掛ければいいんだと気付いた。

そうだよね。コード整形にかけたら良かったんだよね。プラグインを検索とかアホなことしたので備忘録しておく。

IDE使うときはJSONをフォーマッターにかける

reformat code でjson 整形が一発。

スクラッチファイルを使うとさらに便利。

ちょっとしたファイルの整形くらいなら、 IntelliJ のSractchファイルを使うのが便利。

これは他のファイルにも使えるので覚える便利な手段。

css/ json / xml などなど

いちいちプラグイン入れなくていいですよね

phpstorm や rubymine や pycharm などでも使える手段

2018-05-15 追記。

メニューの画像を追加。

gitで追加したけど要らないファイルを消す(clean Untracked files)

git で作業してて困るのが「追加」ファイルの取扱い

git checkout でファイルの変更を取り消したり、ファイルの編集をなかったコトにすることは出来る

だが、あれこれ試してやっぱり使わなかったファイルを消すことはcheckout ではきない。

touch aaaaaaaaaaaaaaaaa
git checkout
ls
 aaaaaaaaaaaaaaa
##

未追跡のファイルに対して何もしないというのはある意味で便利だし、有能な機能なんだけど。

generator 系でミスったファイルを消したい

クラスのジェネレーションやテンプレの追加とか一発出来るコマンドがあったり、gulp のタスクをみすって作っちゃったファイルとかそういうのをまとめて消したいときにはどうする。

git clean でかいけつ

git clean -n # 消されるファイルをプレビュー
git clean -f # 確認しました。消してください。

これでディレクトリのツリーとワーキングツリーの状態が一致するようになる。

ディレクトリもある場合は、 -d をつける

git clean -f -d

つまりどういうことかというと

git status でコマンドを実行したときに出てくる。 Untracked files を消すということ gitignore で無視してるファイルは対象にならない。

この状態でこの条件でclean してあげれば、クラスのディレクトリ構成にゴミを作っても安心してもとに戻せるからガンガンファイルを足して多少コマンドでミスったくらいでも気にしなくていい。便利。

合わせて覚える git

• git clean -i インタラクティブにファイルを指定する（条件指定とか）
• git clean -x gitignore の対象のファイルを消す
• git stash 作業中のファイルをどける

参考資料

https://stackoverflow.com/questions/61212/how-to-remove-local-untracked-files-from-the-current-git-working-tree

umask の初期設定を全部のユーザーに適用する

umask を全部のユーザーに強制する

umask と グループのsticky ビットを使って、ユーザー間でファイルを共有してファイルのパーミッションをグループで編集できるようにしておくと便利。

/etc/profile

このファイルは必ず読み込まれるので、ここの最上位で設定しておく。

umask 0002

ただし、ユーザーごとの~/profile や bashrc などで上書きが可能

ユーザー間のファイルの共有のこと

Linuxは現在では、ユーザー個別のグループを使うことになっていて、それがデフォルトグループになっているので、複数人でファイルを編集してるとパーミッションエラーで書き込み禁止なファイルが出来てしまったりする。元来、複数人でログインして使いまわすのが前提の「コンピュータ」だったのにね・

関連資料

bashrcの設定の読み込まれる順番 - それマグで！

SSHをSFTPに制限して、ディレクトリを制限(chroot)した専用アカウントを作る - それマグで！

gitコマンドでbranch表示するとlessされるので 常にno-pagerしたい

git のpager 設定したらbranchまでpager 表示される

それは望んでないんだわ。

特定のサブコマンドだけページャーしたい

git のサブコマンドでも git diff はページャーしたいけど、 git branch はページャーしたくない。

ページャー設定してしまうと すべてのコマンドでpager=less が有効になるらしい。こまった。

特定のサブコマンドだけページャーをless→cat にする。

.gitconfig

[pager]
  branch = cat

コマンドから

git config --global pager.branch cat

これで解決。

参考資料

man git-config

nginx + php-fpm で display_startup_erros=on にしてシンタックスエラーを表示する。

nginx と php の連携をしてphp のシンタックスエラーを表示する

php-fpm 側の設定をしてしまうと、サイトごとやファイルごとに設定できないので、困ってた。

  location ~ \.php$ {
    fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    include snippets/fastcgi-php.conf;
    fastcgi_param   PHP_VALUE "display_errors=on
        display_startup_errors=on
        error_reporting = E_ALL
        error_log = /var/log/nginx/foo-bar.error.log
    ";
}

順番を逆にすると動かない。。。

fastcgi_pass が逆になると動かない。なんでや

  location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_param   PHP_VALUE "display_errors=on
        display_startup_errors=on
        error_reporting = E_ALL
        error_log = /var/log/nginx/foo-bar.error.log
    ";
    fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}

passより前に書かないと設定が有効にならない。何だこれハマるぞ。

今回、表示されなくてハマった動作環境はコレ。もしかしたらubuntu / debian のinclude の書き方と関係あるのかな～。

PHP Version  7.0.25-0ubuntu0.16.04.1
nginx version: nginx/1.10.3 (Ubuntu)

npm でインストール済み一覧を整理しアンインストール。

インストール済み一覧を表示する。

インストールの結果を表示するには depth

takuya@~$ npm list -g --depth=0
/usr/local/lib
├── hubot@2.19.0
├── jshint@2.9.5
├── jslint@0.11.0
├── less@2.7.2
├── npm@5.6.0
├── uglify@0.1.5
├── uglify-js@3.1.3
├── uglifyjs@2.4.11
├── undefined@0.1.0
├── update@0.7.4
└── upgrade@1.1.0

インストール一覧を見れる。

インストールした結果の一覧を見ることで、インストールしたものを明示的に消せる。楽。

npm list で検索結果が。。。

ふつうに一覧を検索すると大変なことに。

npm -g list

インストールされてるパッケージ結果が、、、すげぇ多すぎ。 インストール一覧を見るとゴチャゴチャ

  │ │ │   └── os-tmpdir@1.0.2 deduped
  │ │ ├─┬ figures@1.7.0
  │ │ │ ├── escape-string-regexp@1.0.5 deduped
  │ │ │ └── object-assign@4.1.1 deduped
  │ │ ├── lodash@4.17.4 deduped
  │ │ ├── mute-stream@0.0.6
  │ │ ├── pinkie-promise@2.0.1 deduped
  │ │ ├── run-async@2.3.0 deduped
  │ │ ├── rx@4.1.0
  │ │ ├─┬ string-width@1.0.2
  │ │ │ ├── code-point-at@1.1.0 deduped
  │ │ │ ├─┬ is-fullwidth-code-point@1.0.0
  │ │ │ │ └── number-is-nan@1.0.1 deduped
  │ │ │ └── strip-ansi@3.0.1 deduped
  │ │ ├── strip-ansi@3.0.1 deduped
  │ │ └── through@2.3.8 deduped
  │ ├── minimist@1.2.0 deduped
  │ ├─┬ mkdirp@0.5.1
  │ │ └── minimist@0.0.8
  │ ├─┬ npmlog@2.0.4
  │ │ ├── ansi@0.3.1
  │ │ ├─┬ are-we-there-yet@1.1.4
  │ │ │ ├── delegates@1.0.0
  │ │ │ └── readable-stream@2.3.3 deduped
  │ │ └─┬ gauge@1.2.7
  │ │   ├── ansi@0.3.1 deduped
  │ │   ├── has-unicode@2.0.1
  │ │   ├── lodash.pad@4.5.1
  │ │   ├── lodash.padend@4.6.1
  │ │   └── lodash.padstart@4.6.1
  │ └── object-assign@4.1.1 deduped
  ├── titleize@1.0.0

えっと、ドレをインストールしたっけ

深さを指定して検索すると何を入れたか解るので助かったのでメモ。

npm list -g --depth=0

不便なので、alias を作っておく

alias npm_installed='npm list --depth=0 '

npm_installed -g 

アンインストールしてみた。

takuya@~$ npm -g uninstall  pug
removed 57 packages in 0.706s

pug だけで 60 近いパッケージに依存してる。さすがパッケージ地獄のnpm だった。

インストールでえらーになったときに困った。

どのパッケージがぶっ壊れたのかを探してて地獄を見た。

npm で gitbook をインストールした

takuya@~$ npm -g install gitbook gitbook-cli
npm WARN deprecated ignore@3.1.2: several bugs fixed in v3.2.1
npm WARN deprecated tough-cookie@2.2.2: ReDoS vulnerability parsing Set-Cookie https://nodesecurity.io/advisories/130
npm WARN deprecated node-uuid@1.4.8: Use uuid module instead
/usr/local/bin/gitbook -> /usr/local/lib/node_modules/gitbook-cli/bin/gitbook.js
/usr/local/bin/gitbook -> /usr/local/lib/node_modules/gitbook/bin/gitbook.js

> fsevents@1.1.3 install /usr/local/lib/node_modules/gitbook/node_modules/fsevents
> node install

[fsevents] Success: "/usr/local/lib/node_modules/gitbook/node_modules/fsevents/lib/binding/Release/node-v59-darwin-x64/fse.node" is installed via remote
+ gitbook-cli@2.3.2
+ gitbook@3.2.3
added 1312 packages in 36.976s

２つ入れるのに、ほぼまっさらな状態から、1312 パッケージですか。。多いな。

npm インストールでぶっ壊して復旧に１時間近くかかったのでメモ

git log --graph でマージ状況がよくわかる。

git のコミット履歴を線にして表示してくれる。

 git log --pretty=format:'%h %s' --graph

出力結果はコレ

このような形で、ブランチの履歴がよくわかる。。

* 9504829 say hello world
* daa290b さぎょうちゅうー
* 7a385a4 ハローワールド
* 2bf15e1 サンプルブランチでの更新
* 460e6a0 ローカルブランチでコミット
* d5e9ee2 作ったブランチへコミット
*   4928e4d Merge branch 'test' into 'master'
|\
| * 85a29cc test
|/
* dba3ada add README

オプションの有無で色々

git log --graph
git log --pretty=format:'%h %s' --graph
git log --graph --pretty=oneline 

~/.gitconfig に書いておくと便利

[alias]
  graph= log  --graph

参考資料

Git - リビジョンの選択

http://blog.toshimaru.net/git-log-graph/

gitで作業中の内容をブランチ（リモート）として扱う。

作業内容をぱぱっとブランチにまとめる。

最初から目的別のブランチ切って作業できるほど人は賢くない。

アレコレ触ってるうちに、ライブラリに欠陥を見つけたり、作業目的とは違うファイルもついでに編集したりとか。 そういう、細々としたコミットをコミットに積み重ねるのも面倒くさい。

たとえば、コミット内容をカテゴリ別にステージングするときに git add -p を叩いてファイルを見ながら目的部分だけ拾って comitt / push って意外と効率が悪い。

stash してあとで考えようとしてもstash から戻すときにマージ考えるのも面倒だし。

その状態でいったん保存したい。

ステージングされてないコミットがまだまだあるんだけど、その状態でいったん保存したい。

帰宅時間が来たぞ帰ろう。とりあえず作業内容をブランチにしてみることにした。

あるブランチで作業をしていて、会議時間前になったし、そろそろ一段落させるか。帰宅時間が近づいたけど今日の進捗なしはこまるな−ってときに。

ファイルが更新状態になってる。

takuya@sample$ echo '<?php phpinfo();?>' > info.php
takuya@sample$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.

Changes not staged for commit:

    modified:   info.php

ブランチを作る

takuya@sample$ git checkout -b working
M   info.php
Switched to a new branch 'working'

ブランチをコミットしてリモートpush する

ブランチをコミットする。

takuya@sample$ git commit -m 'さぎょうちゅうー' info.php
[working daa290b] さぎょうちゅうー
 1 file changed, 1 insertion(+)

ブランチをまるっとプッシュする

takuya@sample$ git push origin working
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 533 bytes | 533.00 KiB/s, done.
Total 6 (delta 2), reused 0 (delta 0)
To example:takuya/sample.git
 * [new branch]      working -> working

状態を確認する。

takuya@sample$ git branch -a
  master
* working
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/working

作業中の状態を保存できた

これであとはまた別のことを始めたら良いわけですね。ブランチに進捗あります。

定時に上がって、家のPCで仕事の続きができますね！

git でローカルにブランチを作ってリモート(origin) にブランチをpush するまでの手順

ブランチをちょっとだけ使いこなす。

リモートに存在しないブランチを手元で作ってプッシュするまでの流れ。

レポジトリを持ってくる。

takuya@Desktop$ git clone git@example.com.:takuya/sample.git
takuya@Desktop$ cd sample/

現在のブランチを確認する。

リモートブランチを含め、現在あるブランチを確認する。

takuya@sample$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

ブランチを作成する。

ブランチを作成する(今回はリモートのmaster からブランチを作成）

takuya@sample$ git checkout -b  サンプルブランチ origin/master
Branch 'サンプルブランチ' set up to track remote branch 'master' from 'origin'.
Switched to a new branch 'サンプルブランチ'

ブランチが切られていることを確認する。

ブランチが切られていることを確認する。

takuya@sample$ git branch -a
  master
* サンプルブランチ
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
takuya@sample$ touch index.php
takuya@sample$ git add .

ローカルブランチへコミットする。

ブランチに変更を加えてみる。

takuya@sample$ git commit -m '作ったブランチへコミット'
[サンプルブランチ d5e9ee2] 作ったブランチへコミット
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 index.php
takuya@sample$ git push
Everything up-to-date

リモート(origin) にブランチを転送する。

コミットが出来たら、リモートに「ブランチ」を送信する。このときにリモートブランチが作成される。

takuya@sample$ git push origin サンプルブランチ
Counting objects: 2, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 294 bytes | 294.00 KiB/s, done.
Total 2 (delta 0), reused 0 (delta 0)
remote:
remote: To create a merge request for サンプルブランチ, visit:
remote:   https://example.com/takuya/sample/merge_requests/new?merge_request%5Bsource_branch%5D=%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81
remote:
To example.com:takuya/sample.git
 * [new branch]      サンプルブランチ -> サンプルブランチ

ローカルブランチの状態を確認する。

remotes/origin/サンプルブランチ として、リモート(origin) にさっきのブランチが追加されてる。 これで、ローカルにあるブランチからリモートブランチ（新規作成）が出来たことが解る。

takuya@sample$ git branch -a
  master
*  サンプルブランチ
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/サンプルブランチ

ブランチが出来たら、マージ

ブランチが出来たら、次はマージするのですが、マージ作業をブラウザで出来るのがgithub のプルリクの強みだったりするのでいいよね。

ブランチ間のマージ

マージするときは master にマージしていくのが基本方針として、ブランチでの作業が少し進んでいる状態をmaster にマージする感じ。

master をチェックアウトして

takuya@sample$ git checkout master

サンプルブランチを取り込む

takuya@sample$ git  merge サンプルブランチ
Updating 460e6a0..2bf15e1
Fast-forward
 bashrc | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bashrc

取り込んだ、マージをリモートに送信する。

takuya@sample$ git push
Counting objects: 2, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.

ローカルブランチを削除する。

takuya@sample$ git branch -d サンプルブランチ
Deleted branch サンプルブランチ (was 2bf15e1).

必要がなくなったリモートのブランチを消す。

リモートにブランチを削除するpush をする。

takuya@sample$ git push --delete origin サンプルブランチ
To example.com:takuya/sample.git
 - [deleted]         サンプルブランチ

まとめ

ローカルでブランチを作って、ブランチを送信できる

ブランチをマージするのは手元でやるのが基本。サーバー側でまとめて出来るのがgithub の魅力

リモートのブランチへの削除push が出来る

これで、帰宅時間が来たら帰宅時間ブランチを作ってpushすれば良いことが解る。

参考資料

ちょっと進んだGit, Githubの使い方~ブランチ活用編~ - nigoblog

シェルのalias されたコマンドの展開する - alias-expand-line

シェルのコマンドを展開したい。

composite 使おうとしたら、候補多すぎて面倒くさい。補完が補完にならないよね

takuya@~$ com<tab>
comm       command    compare    compgen    complete   compopt    composer   composite  compress   comsat

最初の３文字くらいで、展開されてほしい。 bashの補完で completion を書いても現在位置は置換できないし、alias で短縮しても履歴に元のコマンドを残したい。

alias してみてもうまくいかない。

alias すると、たしかに短くなるのだけど、履歴が汚れる。すげぇ面倒くさいわ。

alias comp=composite
history
997: comp
998: comp
999: comp

sysout<tab> が System.out.println() になるような短縮(abbreviation)と補完(completion)をやりたいと思ってました。

alias-expand-line で解決する

ショートカットキー<ctl-alt-e> を押すと、展開される。これだ！

$ ll<ctl-alt-e>

こうなる

$ ls -lt 

これだ。

参考資料

https://superuser.com/questions/247770/how-to-expand-aliases-inline-in-bash

https://unix.stackexchange.com/questions/158038/non-interactive-shell-expand-alias

dockerのexpose のポートをlocalhostに限定する。

docker のポートのIPアドレスを限定したい。

expose したポートを、bind するときに、よく見る例がコレ

docker  run -p 80:80 ...

コレだと、0.0.0.0:80 にマッピングされる。グローバルアドレスにマッピングしてしまうのですよね。ちょっと先行き不安。

ローカル・ループバックに限定する

docker  run -p 127.0.0.1:80:80 ...

IPv6の ループバックはダメみたい

::1 はダメだった。悲しい。そのうちなんとかなるかも。

takuya@ubuntu01:~/docker-test$ docker-compose up -d
ERROR: The Compose file './docker-compose.yml' is invalid because:
services.db.ports is invalid: Invalid port "::1:5432:5432", should be [[remote_ip:]remote_port[-remote_port]:]port[/protocol]

docker-compose の場合

docker-compose の yml の場合はこう書くといいみたい。

    ports:
      - 127.0.0.1:5432:5432

なるほど、コレだとループバックだからiptables も考えなくていいから安心ですね。

参考資料

https://docs.docker.com/compose/compose-file/#ports

https://stackoverflow.com/questions/45109398/how-can-i-make-docker-compose-bind-the-containers-only-on-defined-network-instea

docker の mysql に sql を流し込んでデータベースを作ったり初期データをいれる

docker のmysql にデータを流し込みたい。

docker のmysql にデータ流し込む

docker exec -i 49723f3d7ed1  mysql -uroot -pPASWORD database_name < data.sql

exec のオプションに -it ではなく tty なしで -i だけでいい。

データベースにデータを投入するためだけに Dockerfile から COPY とか EXPOSE 3306 とか VOLUMEするのも面倒な話なので。

データベースにデータを投入したことを確認したい。

bash などを経由しなくても直接 tty を繋いで mysql のコンソールに繋いであげれば良いことが解る。

docker exec -it 49723f3d7ed1  mysql -uroot -pPASWORD database_name 

これでOK

docker-composeの管理が面倒なのでerb と makefileにした

docker-compose.yml が面倒くさい。

docker-compose は良く出来てるんだけど、環境変数だとか環境設定がめんどくさくないですか？

dockerfile から docker-compose.yml に進化して相当使いやすくなってるのはわかるんですね。

でも不便なものは不便。

コメントとか変数とか書きたい。

yml syntax チェックとかかしたい。

erb で変換することにしたら楽だった。

$ erb docker-compose.erb.yml | ruby -ryaml -e 'puts YAML.dump(YAML.load(ARGF.read()))' > docker-compose.yml

erb 変換して、その結果をruby の YAML に流し込んで整形することにした。 結構複雑なコメントとか書けるようになって嬉しかった。

makefile も併せて作った。

• erb → yml に変換する
• yml → docker 起動

この辺のワークフローをmakefile で作った。

name=php-apache-mysql
registry=takuya.registory.example.com/takuya/docker/$(name)

conf=docker-compose.yml
project-name=my$(name)
compose=docker-compose
cmd=$(compose) -f $(conf) --project-name $(project-name)

docker-compose.yml: docker-compose.erb.yml
    erb docker-compose.erb.yml | ruby -ryaml -e 'puts YAML.dump(YAML.load(ARGF.read()))' > $(conf)


.PHONY: all build run up down registory push clean

all: build

build:  docker-compose.yml
    $(cmd) build
run: build
    $(cmd) up
up: build
    $(cmd) up -d
down:
    $(cmd) down
kill-all:
    $(cmd) down

registry:
    @docker build -t $(registry) .
push: registry
    @docker push $(registry)
clean:
    -rm $(conf)

makefile 楽だわ。

gulp とかこういうビルドシステムは数あるけど、シンプルにやりたいことがぱぱっと出来るので 古き良きツールもまだまだ見捨てたらかわいそうだなって思った的な。