Make datalad-annex:: compatible with datalad-osf

[mih]

The git-remote-osf helper of https://github.com/datalad/datalad-osf is the director predecessor of datalad-annex::. It suffers from a number of limitations that have since been improved in datalad-annex::. Therefore it would be nice to be able to use the latter instead of the former without loosing data access.

There are two issues. One is

• Make datalad-annex:: compatible with datalad-osf repo deposits datalad-next#410

The other is that datalad-annex:: used the XDLRA annex backend to deposit repositories, while the datalad-osf special remote hard-codes the target files for such keys. The content is, however, exactly identical.

One solution would be to transparently map between the hard-coded locations and the respective XDLRA keys. Possible like this:

diff --git a/datalad_osf/annex_remote.py b/datalad_osf/annex_remote.py
index c264f64..55dc45f 100755
--- a/datalad_osf/annex_remote.py
+++ b/datalad_osf/annex_remote.py
@@ -253,6 +253,13 @@ class OSFSpecialRemote(ExportRemote):
                 f.path.lstrip(posixpath.sep): f
                 for f in self.storage.files
             }
+            for p, key in (
+                ('.git/refs', 'XDLRA--refs'),
+                ('.git/repo.zip', 'XDLRA--repo-export'),
+            ):
+                handle = self._files.get(p)
+                if handle is not None:
+                    self._files[key] = handle
         return self._files
 
     def removeexportdirectory(self, remote_directory):

Some additional though needs to go into transitions. I see two scenarios:

• Keep the hard-coded names and map to XDLRA key names on read and on write. There would be no change to the layout on OSF (good). But the first write via datalad-annex:: would make the deposit incompatible with git-remote-osf (relevant for existing clones). So this would also need an update
• Transition to XDLRA by mapping on read, but not on write. This would make things more uniform across special remotes and expectations, but would require datalad-osf users to transition to datalad-annex:: explicitly, or also require an update to git-remote-osf.

I am leaning towards the first solution. This would be the approach:

• implement two-way mapping to keep the OSF project content identical wrt file names, and enable direct use of git-annex-remote-osf with datalad-annex:: (assuming Make datalad-annex:: compatible with datalad-osf repo deposits datalad-next#410 is implemented)
• replace git-remote-osf to become a thing wrapper around datalad-annex::

OSF users would be required to upgrade datalad-osf whenever the update an OSF deposit via datalad-annex:: or via an upgraded git-remote-osf. The latter would be OK, given the software upgrade has already happened. The former requires an intentional change on the user end -- OK too IMHO.