-
Notifications
You must be signed in to change notification settings - Fork 14
/
Copy pathREADME
93 lines (67 loc) · 3.12 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
DEP(1)
NAME
dep -- Basic dependency tracking
SYNOPSIS
dep
dep add libname [--pre]
dep rm libname
dep install
DESCRIPTION
dep
Checks that all dependencies are met.
dep add [gemname]
Fetches the latest version of `gemname`
and automatically adds it to your .gems file.
rm
Removes the corresponding entry in your .gems file.
install
Installs all the missing dependencies for you. An important
point here is that it simply does a `gem install` for each
dependency you have. Dep assumes that you use some form of
sandboxing like gs, rbenv-gemset or RVM gemsets.
INSTALLATION
$ wget -qO- http://amakawa.org/sh/install.sh | sh
# or
$ gem install dep
HISTORY
dep is actually more of a workflow than a tool. If you think about
package managers and the problem of dependencies, you can summarize
what you absolutely need from them in just two points:
1. When you build an application which relies on 3rd party libraries,
it's best to explicitly declare the version numbers of these
libraries.
2. You can either bundle the specific library version together with
your application, or you can have a list of versions.
The first approach is handled by vendoring the library. The second
approach typically is done using Bundler. But why do you need such
a complicated tool when all you need is simply listing version numbers?
We dissected what we were doing and eventually reached the following
workflow:
1. We maintain a .gems file for every application which lists the
libraries and the version numbers.
2. We omit dependencies of dependencies in that file, the reason being
is that that should already be handled by the package manager
(typically rubygems).
3. Whenever we add a new library, we add the latest version.
4. When we pull the latest changes, we want to be able to rapidly
check if the dependencies we have is up to date and matches what
we just pulled.
So after doing this workflow manually for a while, we decided to
build the simplest tool to aid us with our workflow.
The first point is handled implicitly by dep. You can also specify
a different file by doing dep -f.
The second point is more of an implementation detail. We thought about
doing dependencies, but then, why re-implement something that's already
done for you by rubygems?
The third point (and also the one which is most inconvenient), is
handled by dep add.
The manual workflow for that would be:
gem search -r "^ohm$" [--pre] # check and remember the version number
echo "ohm -v X.x.x" >> .gems
If you try doing that repeatedly, it will quickly become cumbersome.
The fourth and final point is handled by typing dep check or simply dep.
Practically speaking it's just:
git pull
dep
And that's it. The dep command typically happens in 0.2 seconds which
is something we LOVE.