82
82
=======================
84
84
All Path objects support a common set of operations, suitable
85
for many use cases and allowing to transparently switch the
86
path object within an application (e.g. from "local" to "svnwc").
87
The common set includes functions such as `path.read()` to read all data
88
from a file, `path.write()` to write data, `path.listdir()` to get a list
85
for many use cases and allowing to transparently switch the
86
path object within an application (e.g. from "local" to "svnwc").
87
The common set includes functions such as `path.read()` to read all data
88
from a file, `path.write()` to write data, `path.listdir()` to get a list
89
89
of directory entries, `path.check()` to check if a node exists
90
90
and is of a particular type, `path.join()` to get
91
91
to a (grand)child, `path.visit()` to recursively walk through a node's
92
children, etc. Only things that are not common on 'normal' filesystems (yet),
92
children, etc. Only things that are not common on 'normal' filesystems (yet),
93
93
such as handling metadata (e.g. the Subversion "properties") require
97
97
---------------------------------
230
230
===================================
232
232
* The SVN path objects require the "svn" command line,
233
there is currently no support for python bindings.
233
there is currently no support for python bindings.
234
234
Parsing the svn output can lead to problems, particularly
235
regarding if you have a non-english "locales" setting.
235
regarding if you have a non-english "locales" setting.
237
* While the path objects basically work on windows,
237
* While the path objects basically work on windows,
238
238
there is no attention yet on making unicode paths
239
work or deal with the famous "8.3" filename issues.
239
work or deal with the famous "8.3" filename issues.
244
244
The Subversion path implementations are based
245
on the `svn` command line, not on the bindings.
246
It makes sense now to directly use the bindings.
245
on the `svn` command line, not on the bindings.
246
It makes sense now to directly use the bindings.
248
Moreover, it would be good, also considering
248
Moreover, it would be good, also considering
249
249
`execnet`_ distribution of programs, to
250
250
be able to manipulate Windows Paths on Linux
251
251
and vice versa. So we'd like to consider
252
refactoring the path implementations
252
refactoring the path implementations
253
253
to provide this choice (and getting rid
254
of platform-dependencies as much as possible).
254
of platform-dependencies as much as possible).
256
There is some experimental small approach
256
There is some experimental small approach
257
257
(``py/path/gateway/``) aiming at having
258
a convenient Remote Path implementation.
258
a convenient Remote Path implementation.
260
260
There are various hacks out there to have
261
261
Memory-Filesystems and even path objects
262
being directly mountable under Linux (via `fuse`).
263
However, the Path object implementations
264
do not internally have a clean abstraction
262
being directly mountable under Linux (via `fuse`).
263
However, the Path object implementations
264
do not internally have a clean abstraction
265
265
of going to the filesystem - so with some
266
refactoring it should become easier to
266
refactoring it should become easier to
267
267
have very custom Path objects, still offering
268
the quite full interface without requiring
269
to know about all details of the full path
268
the quite full interface without requiring
269
to know about all details of the full path
272
272
.. _`execnet`: execnet.html
added
removed
doc/path.txt
