use `pyfilesystem` library instead of our own-rolled classes

[GoogleCodeExporter]

1) What part of the model would need changes:

The `Transport` class, especially `SshTrasport`,
and its clients.

2) What is the reason why the changes is proposed:

We need to operate on possibly remote filesystems via SSH; this is
currently done by methods in the `Transport` class that mimick the
operation of `os.path` functions.

However, as complexity of GC3Libs increases, larger parts of `os.path`
need to be reimplemented in the `Transport` class.  At some point, we
might even need to reimplement the same functionality for GridFTP.

It is thus sensible to look for a library that provides a "virtual
filesystem" implementation in Python and leverage on it.

3) What is the proposal:

Use the `pyfilesystem` library:

  http://code.google.com/p/pyfilesystem/

Delegate all filesystem operations to instances of the `pyfilesystem`
library, and remove support for filesystem operations from `Trasport`.
`Transport` should remain only a way of executing remote commands.

Note that the PyFilesystem library name on PyPI is `fs`!

Original issue reported on code.google.com by riccardo.murri@gmail.com on 14 Apr 2011 at 2:01

[GoogleCodeExporter]

sounds reasonable
but at the same time
I would be extra careful in adopting components that cannot guarantee a
minimal extended lifetime

this is a 1 developer project
although is already 4 years old

are we sure about that ?

Sergio :)

Original comment by sergio.m...@gmail.com on 14 Apr 2011 at 2:58

[GoogleCodeExporter]

| I would be extra careful in adopting components that cannot guarantee a
| minimal extended lifetime
|
| this is a 1 developer project
| although is already 4 years old

If the alternative is rolling our own classes, what do we lose by
using another open-source project?  Worst case, we'll have to maintain
its code, like we already do with transport.py...

Anyway, the SVN log shows commits from two people, and they seem quite active.

Original comment by riccardo.murri@gmail.com on 14 Apr 2011 at 3:03

[GoogleCodeExporter]

Original comment by riccardo.murri@gmail.com on 20 Jun 2012 at 6:40

[GoogleCodeExporter]

I am currently playing with pyfilesystem. The main problem I've just found is 
that when you use the "fs.opener.opener" class with a url like "sftp://" it 
does not use automatically ssh public key authentication. 

For example, in my machine I can just ssh to localhost with "ssh localhost" 
using p-key authentication. However, this code will not work:

from fs.opener import opener
remote = opener.parse("sftp://localhost")

because it is not using my public keys. To make it work, I have to *specify* 
which public key I want to use and create an instance of te fs.sftpfs.SFTPFS 
class:

from fs.sftpfs import SFTPFS
import paramiko

pkey = paramiko.DSSKey(filename='.ssh/id_dsa')
fs = SFTPFS('localhost',pkey=pkey)

This means that either we parse the ``.ssh/config`` configuration file (BAD) or 
we have to fix the sftpfs nodule, therefore we would have have to fork, patch 
with their python-24 patch, patch the sftpfs code and maintain a lot of stuff 
we don't actually care about.

I've just joined pyfilesystem's discussion group though, let's see how they 
repsond.

Original comment by arcimbo...@gmail.com on 28 Jun 2012 at 3:54