vfs 0.4.0 → 0.4.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/Rakefile +1 -1
- data/lib/vfs/entries/entry.rb +1 -1
- data/lib/vfs/path.rb +1 -3
- data/readme.md +76 -69
- data/spec/path_spec.rb +2 -0
- metadata +2 -2
data/Rakefile
CHANGED
data/lib/vfs/entries/entry.rb
CHANGED
data/lib/vfs/path.rb
CHANGED
@@ -84,12 +84,10 @@ module Vfs
|
|
84
84
|
parts = path.split('/')[1..-1]
|
85
85
|
if parts
|
86
86
|
parts.each do |part|
|
87
|
-
if part == '..' and root != '.'
|
87
|
+
if part == '..' and (root != '.' or (root == '.' and result.size > 0))
|
88
88
|
return nil, false unless result.size > 0
|
89
89
|
result.pop
|
90
90
|
probably_dir ||= true
|
91
|
-
# elsif part == '.'
|
92
|
-
# # do nothing
|
93
91
|
else
|
94
92
|
result << part
|
95
93
|
probably_dir &&= false
|
data/readme.md
CHANGED
@@ -1,111 +1,118 @@
|
|
1
|
-
|
1
|
+
Virtual File System provides **clean, simple and unified API over different storage systems** (Local File System, AWS S3, SFTP, Hadoop DFS, LDAP, Document Oriented DBs, In-Memory, ...).
|
2
|
+
It is possible to provide such unified API because although those storages have different API the core concept are almost the same.
|
2
3
|
|
3
|
-
|
4
|
-
The Vfs for File System is kinda the same as ActiveRecord is for Relational Databases.
|
5
|
-
|
6
|
-
Currently, there are following implementations available:
|
7
|
-
|
8
|
-
- local file system
|
9
|
-
- remote file system (over ssh)
|
4
|
+
Currently, there are following implementations available: Local FS, SFTP, S3.
|
10
5
|
|
11
6
|
## Goals
|
12
7
|
|
13
8
|
- **handy, simple and clean** API.
|
14
9
|
- same API for different storages (Local FS, SSH, Hadoop, or any other , ...).
|
15
10
|
- should work **simultaneously with different storages**.
|
16
|
-
- small codebase, easy to extend
|
17
|
-
-
|
11
|
+
- small codebase, easy to extend and understand.
|
12
|
+
- driver implementation should be simple, is should be easy to create new drivers.
|
18
13
|
|
19
|
-
|
14
|
+
## Example:
|
20
15
|
|
21
|
-
|
22
|
-
- copy: right now it doesn't use FileUtils.cp_r, it walks on the directory tree and copy each entry individually, so it's probably a little slover.
|
23
|
-
- right now :move and :rename implemented ASAP by copy & destroy, will be fixed as soon as I'll have time to do it.
|
16
|
+
The script below runs on local file system, to see this script running on S3 and SFTP please take a look at the examples folder, there are also samples for S3 backup and deployment over SSH/SFTP.
|
24
17
|
|
25
|
-
|
18
|
+
``` ruby
|
19
|
+
require 'vfs'
|
26
20
|
|
27
|
-
|
28
|
-
|
29
|
-
$ gem install vos
|
30
|
-
```
|
21
|
+
# Preparing temporary dir for sample and cleaning it before starting.
|
22
|
+
sandbox = '/tmp/vfs_sandbox'.to_dir.destroy
|
31
23
|
|
32
|
-
|
24
|
+
# Let's create simple Hello World project.
|
25
|
+
project = sandbox['hello_world'] # Our Hello World project.
|
33
26
|
|
34
|
-
|
35
|
-
|
36
|
-
require 'vos' # Virtual Operating System
|
27
|
+
project['readme.txt'].write 'My shiny App' # Writing readme file, note that parent dirs
|
28
|
+
# where created automatically.
|
37
29
|
|
38
|
-
#
|
30
|
+
# File operations.
|
31
|
+
readme = project['readme.txt']
|
39
32
|
|
40
|
-
|
41
|
-
|
33
|
+
# Checking that it's all ok with our readme.
|
34
|
+
p readme.name # => readme.txt
|
35
|
+
p readme.path # => /.../readme.txt
|
36
|
+
p readme.exist? # => true
|
37
|
+
p readme.file? # => true
|
38
|
+
p readme.dir? # => false
|
39
|
+
p readme.size # => 12
|
40
|
+
p readme.created_at # => 2011-09-09 13:20:43 +0400
|
41
|
+
p readme.updated_at # => 2011-09-09 13:20:43 +0400
|
42
42
|
|
43
|
-
|
44
|
-
|
43
|
+
# Reading.
|
44
|
+
p readme.read # => "My shiny App"
|
45
|
+
readme.read{|chunk| p chunk} # => "My shiny App"
|
45
46
|
|
46
|
-
#
|
47
|
+
# Writing.
|
48
|
+
readme.append "2 + 2 = 4"
|
49
|
+
p readme.size # => 21
|
47
50
|
|
48
|
-
|
51
|
+
readme.write "My shiny App v2" # Writing new version of readme.
|
52
|
+
p readme.read # => "My shiny App v2"
|
49
53
|
|
50
|
-
#
|
54
|
+
readme.write{|s| s.write "My shiny App v3"} # Writing another new version of readme.
|
55
|
+
p readme.read # => "My shiny App v3"
|
51
56
|
|
52
|
-
|
53
|
-
|
54
|
-
|
55
|
-
|
57
|
+
# Copying & Moving.
|
58
|
+
readme.copy_to project['docs/readme.txt'] # Copying to ./docs folder.
|
59
|
+
p project['docs/readme.txt'].exist? # => true
|
60
|
+
p readme.exist? # => true
|
56
61
|
|
57
|
-
|
58
|
-
|
59
|
-
|
62
|
+
readme.move_to project['docs/readme.txt'] # Moving to ./docs folder.
|
63
|
+
p project['docs/readme.txt'].exist? # => true
|
64
|
+
p readme.exist? # => false
|
60
65
|
|
61
|
-
projects['cool_app/config/database.yml']. # or just overwrite it with our local dev version
|
62
|
-
copy_to! dbc
|
63
|
-
```
|
64
66
|
|
65
|
-
|
67
|
+
# Dir operations.
|
68
|
+
project.file('Rakefile').create # Creating empty Rakefile.
|
66
69
|
|
67
|
-
#
|
70
|
+
# Checking our project exists and not empty.
|
71
|
+
p project.exist? # => true
|
72
|
+
p project.empty? # => false
|
68
73
|
|
69
|
-
|
70
|
-
|
71
|
-
|
72
|
-
|
74
|
+
# Listing dir content.
|
75
|
+
p project.entries # => [/.../docs, .../Rakefile]
|
76
|
+
p project.files # => [/.../Rakefile]
|
77
|
+
p project.dirs # => [/.../docs]
|
78
|
+
project.entries do |entry| # => ["docs", false]
|
79
|
+
p [entry.name, entry.file?] # => ["Rakefile", true]
|
80
|
+
end
|
81
|
+
p project.include?('Rakefile') # => true
|
82
|
+
|
83
|
+
# Copying & Moving, let's create another project by cloning our hello_world.
|
84
|
+
project.copy_to sandbox['another_project']
|
85
|
+
p sandbox['another_project'].entries # => [/.../docs, .../Rakefile]
|
73
86
|
|
74
|
-
|
75
|
-
|
87
|
+
# Cleaning sandbox.
|
88
|
+
sandbox.destroy
|
76
89
|
```
|
77
90
|
|
78
|
-
|
91
|
+
API is the same for all storage types (Local, S3, SFTP, ...). Also API are the same for transfers (copy_to, move_to, ...) between any storage types.
|
92
|
+
So, for example backup from S3 looks exactly the same as if files are located on the local folder.
|
79
93
|
|
80
|
-
|
81
|
-
config = deploy_dir['config']
|
82
|
-
config.parent # => </apps/cool_app>
|
83
|
-
config['../..'] # => </>
|
84
|
-
config['../..'].dir? # => true
|
85
|
-
|
86
|
-
deploy_dir.entries # => list of dirs and files, also support &block
|
87
|
-
deploy_dir.files # => list of files, also support &block
|
88
|
-
deploy_dir.dirs # => list of dirs, also support &block
|
89
|
-
```
|
94
|
+
## Installation
|
90
95
|
|
91
|
-
|
96
|
+
``` bash
|
97
|
+
$ gem install vfs
|
98
|
+
|
99
|
+
# For S3 and SFTP support install also vos
|
100
|
+
$ gem install vos
|
101
|
+
```
|
92
102
|
|
93
103
|
## Integration with [Vos][vos] (Virtual Operating System)
|
94
104
|
|
95
|
-
|
96
|
-
|
97
|
-
```
|
105
|
+
Vfs can be used toghether with the Virtual Operating System Tool, and while the Vfs covers all the I/O operations the Vos provides support for remote command execution.
|
106
|
+
You can use this combination to fully control remote machines, for example - I'm using it to manage my production servers (setup, administration, deployment, migration, ...).
|
98
107
|
|
99
108
|
For more details please go to [Vos][vos] project page.
|
100
|
-
|
101
|
-
configuration tool [Cluster Management][cluster_management].
|
109
|
+
You can also take look at the actual configuration I'm using to control my servers [My Cluster][my_cluster] (in conjunction with small configuration tool [Cluster Management][cluster_management]).
|
102
110
|
|
103
111
|
# Why?
|
104
112
|
|
105
|
-
To easy my work: with local FS, remote FS
|
113
|
+
To easy my work: with local FS, remote FS, and some specific systems like Hadoop DFS.
|
106
114
|
|
107
|
-
Because the API of standard File/Dir/FileUtils classes are just terrible. And there's the reason for it - the goal of thouse tools
|
108
|
-
is to provide 1-to-1 clone of underlying OS API, instead of provididing handy tool.
|
115
|
+
Because the API of standard File/Dir/FileUtils classes are just terrible. And there's the reason for it - the goal of thouse tools is to provide 1-to-1 clone of underlying OS API, instead of provididing handy tool.
|
109
116
|
|
110
117
|
And if you want to use remote FS - things are getting even worse and more complicated (Net::SSH & Net::SFTP use a little
|
111
118
|
different API than local FS, and you has to remember all thouse little quirks).
|
data/spec/path_spec.rb
CHANGED
metadata
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: vfs
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 0.4.
|
4
|
+
version: 0.4.1
|
5
5
|
prerelease:
|
6
6
|
platform: ruby
|
7
7
|
authors:
|
@@ -9,7 +9,7 @@ authors:
|
|
9
9
|
autorequire:
|
10
10
|
bindir: bin
|
11
11
|
cert_chain: []
|
12
|
-
date: 2011-09-
|
12
|
+
date: 2011-09-09 00:00:00.000000000Z
|
13
13
|
dependencies: []
|
14
14
|
description:
|
15
15
|
email:
|