ytools 0.1.0 → 0.1.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- data/README.markdown +76 -0
- data/lib/VERSION +1 -1
- data/lib/ytools/path/cli.rb +2 -1
- metadata +6 -5
data/README.markdown
ADDED
@@ -0,0 +1,76 @@
|
|
1
|
+
# YTools
|
2
|
+
|
3
|
+
These are a couple of YAML-based tools for working with configuration files.
|
4
|
+
|
5
|
+
### YPath
|
6
|
+
|
7
|
+
The first tool, ypath, be used to pull values from a YAML configuration and print
|
8
|
+
them to STDOUT. It's quite useful if you need to use the YAML as a configuration
|
9
|
+
and only pull out individual values for your other scripts to use.
|
10
|
+
|
11
|
+
Say you have a YAML configuration file like:
|
12
|
+
|
13
|
+
project:
|
14
|
+
name: C.proj
|
15
|
+
dependencies:
|
16
|
+
- A.proj
|
17
|
+
- B.proj
|
18
|
+
|
19
|
+
You could then pull out the project name 'C.proj' by running
|
20
|
+
|
21
|
+
ytools -p /project/name YAML_FILE
|
22
|
+
|
23
|
+
You could even list all of the dependencies by running
|
24
|
+
|
25
|
+
ytools -p /project/dependencies YAML_FILE
|
26
|
+
|
27
|
+
which would print
|
28
|
+
|
29
|
+
A.proj
|
30
|
+
B.proj
|
31
|
+
|
32
|
+
### YTemplates
|
33
|
+
|
34
|
+
The second tool, ytemplates, be used to generate configuration files
|
35
|
+
that use YAML files as the backing object binding. A simple use case might
|
36
|
+
be that you need a configuration file generated for an environment, and you
|
37
|
+
can break out the environment-specific values into different YAML files.
|
38
|
+
In this case, you could create a file for each environment, one for production
|
39
|
+
|
40
|
+
environment: production
|
41
|
+
database:
|
42
|
+
host: production.host.com
|
43
|
+
username: produser
|
44
|
+
password: imsecret
|
45
|
+
|
46
|
+
and another for testing
|
47
|
+
|
48
|
+
environment: testing
|
49
|
+
database:
|
50
|
+
host: internal-testing.host.com
|
51
|
+
username: testuser
|
52
|
+
password: imsecret
|
53
|
+
|
54
|
+
With those files, you could then create an ERB template to pull in the relevant
|
55
|
+
values like:
|
56
|
+
|
57
|
+
<settings environment="<%= environment =>">
|
58
|
+
<database>
|
59
|
+
<host><%= database.host %></host>
|
60
|
+
<username><%= database.username %></username>
|
61
|
+
<password><%= database.password %></username>
|
62
|
+
</database>
|
63
|
+
</settings>
|
64
|
+
|
65
|
+
Using ytemplates, you could then generate a different environment
|
66
|
+
file from each yaml file, but only have to manage one actual configuration file.
|
67
|
+
Obviously, this becomes much more useful when the number of environments grows
|
68
|
+
and the number of changes in the configuration files goes down relative to file's
|
69
|
+
size.
|
70
|
+
|
71
|
+
## Downloading
|
72
|
+
|
73
|
+
You can download the gem using
|
74
|
+
|
75
|
+
gem install ytools
|
76
|
+
|
data/lib/VERSION
CHANGED
@@ -1 +1 @@
|
|
1
|
-
0.1.
|
1
|
+
0.1.1
|
data/lib/ytools/path/cli.rb
CHANGED
metadata
CHANGED
@@ -1,13 +1,13 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: ytools
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
hash:
|
4
|
+
hash: 25
|
5
5
|
prerelease: false
|
6
6
|
segments:
|
7
7
|
- 0
|
8
8
|
- 1
|
9
|
-
-
|
10
|
-
version: 0.1.
|
9
|
+
- 1
|
10
|
+
version: 0.1.1
|
11
11
|
platform: ruby
|
12
12
|
authors:
|
13
13
|
- Gabe McArthur
|
@@ -42,9 +42,10 @@ executables:
|
|
42
42
|
- ytemplates
|
43
43
|
extensions: []
|
44
44
|
|
45
|
-
extra_rdoc_files:
|
46
|
-
|
45
|
+
extra_rdoc_files:
|
46
|
+
- README.markdown
|
47
47
|
files:
|
48
|
+
- README.markdown
|
48
49
|
- Rakefile
|
49
50
|
- bin/ypath
|
50
51
|
- bin/ytemplates
|