-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Patch RIA and ORA code to work on multiple client platforms #669
Conversation
f2253bf
to
80f7dee
Compare
29cc348
to
652f72c
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #669 +/- ##
==========================================
- Coverage 93.04% 92.41% -0.64%
==========================================
Files 185 193 +8
Lines 12913 14107 +1194
Branches 1950 2126 +176
==========================================
+ Hits 12015 13037 +1022
- Misses 689 808 +119
- Partials 209 262 +53 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few first, very high-level comments:
The PR adds a number of patches that seem to replace all(?) of the ORARemote implementation -- or it is at least not easy to see which parts are left untouched. No all individual patches are documented properly (top-level docstring explaining the purpose).
This makes it hard to understand why these are individual patches, and not just one -- especially given the strong patch order requirements.
From what I can see, all of the following could be one patch (may still be composed of several files):
add_method_url2transport_path
replace_sshremoteio
ria_utils
replace_ora_remote
fix_ria_ora_tests
replace_create_sibling_ria
Please also at some indication where the, then modified, code was taken from. Further changes might be made in datalad-core, and someone would need to figure out which version to compare to. Grep for taken from
in datalad_next/patches
.
ac7eecc
to
36de721
Compare
This commit reloads `cls` in `datalad.customremotes.main._main` to allow `cls` to be patched successfully by `load_extensions()`. This is currently used for `ORARemote`-patching. Note: a nicer solution would be to execute: from datalad.support.entrypoints import load_extensions load_extensions() as first commands in the `main`-function of all remote-implementations. But since this would require changes in datalad-core, it was not done here.
This commit add the method `url2transport_path` to the classes `datalad.distributed.ora_remote.SSHRemoteIO`, `datalad.distributed.ora_remote.LocalIO`, and `datalad.distributed.ora_remote.HTTPRemoteIO`. This method is used to convert the path representation that ORA remote will use internally, i.e. `PurePosixPath`, into a path that can be used with the respective IO-abstraction. The necessary modification in ora_remote are contained in a later commit. This change is made mainly to support RIA clients on all platforms, including Windows.
This commit replaces the complete `ORARemote` class with a patched version that does: - consistently use `PurePosixPath` for RIA-directory operations in RIA-manipulation-code, and use the `url2transport_path`-method to convert these paths into IO-abstraction-specific "real" paths - On Windows-clients: use canonified drive-letter encoding internally, and convert them into annex- or git-specific drive letter encodings before calling the respective methods. With these changes an ORARemote will properly work on Windows.
36de721
to
c929360
Compare
This commit replaces the class `datalad.distributed.create_sibling_ria.CreateSiblingRia`. to adapt its methods to the generic path-handling for RIA-store path manipulation-code. This commit is part of The commit also contains a patch with the neccessary changes to `ria_utils.py`.
This commit adapts tests that use RIA- and ORA-code to use the internal RIA-path representation, i.e. `PurePosixPath`. That has become necessary because the patched RIA code asserts that path-arguments are instances of `PurePosixPath`.
This commit activates the test `datalad_next.patches.tests.test_ria.test_ria_ssh_roundtrip` on Windows. With the previous commits in this branch, the test should now pass.
This commit interprets a None environment value as an empty string. It also ensures that all values are strings instead of, for example, `int`. It adds a paragraph to the doc-string of `datalad_next.config.utils.set_gitconfig_items_in_env` to document its behavior if a configuration item has a `None`-value. This commit is unrelated to Windows-support, but became necessary because the datalad-next CI runs datalad tests now always with the loaded `datalad_next`-extension, and the previous version of datalad_next's config code failed the tests.
Thanks for the feedback. You are right, the source of the code and the amount of modifications are not obvious. I extended the patch to contain the following:
I see your point. I will create a single |
c929360
to
325d89a
Compare
This commit adds a new file that imports all patches for RIA/ORA-related code in a correct order. This file, i.e. `datalad_next.patches.patch_ria_ora.py`, is then imported from `datalad_next.patches.enabled`.
I have tested this on my mac locally, with the following setup (miniconda virtual environment):
I ran the associated tests locally with no errors. I created a local datalad dataset with annexed content, and created a ria sibling in a ria store on the local file system as well as another sibling in a store accessible via SSH (juseless). Both commands ran without errors. Is there anything else I should try out? |
I extracted the config |
Perfect, thanks a lot @jsheunis If you have a Windows system and time on your hands, I would appreciate it if you could do a similar test there. I don't expect everything to work as well as in OSX because the focus was on cloning from a RIA store and getting content from the RIA store on a Windows system. EDIT: tested on Windows: creation of local and SSH-RIA siblings, pushing to the siblings, cloning from the siblings, getting data from the siblings. Worked well. |
a7ffccd
to
558640a
Compare
Merge main into the PR-branch in order to activate appveyor CI-runs.
This commit ensures that Windows and non-Windows URL-canonification code is run on all platforms. This is possible because the code does not depend on platform-specific libraries.
9955ae6
to
585b48d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for tackling this issue. The patch is a monster, but there was no other way. I am glad that its development also led to a generally more correct test behavior.
I tuned the docs a bit and added a changelog.
Thanks!
The patched code is new patch-code, introduced in datalad#669 The assertions were added to make sure that no platform paths are passed around. The Debian maintainer observed non-pure paths coming in. This may need an investigation, but this changeset maintains the spirit of the assertions while relaxing them enough to let the tests pass in a Debian build environment.
Since 1.4.0 a plain `datalad_next` import required `pytest`. This was due to the datalad-core patch `fix_ria_ora_tests` add in datalad#669, and was discovered by Debian's CI Closes: datalad#698 Refs: datalad#669, https://ci.debian.net/packages/d/datalad-next/testing/amd64/46884776/
Since 1.4.0 a plain `datalad_next` import required `pytest`. This was due to the datalad-core patch `fix_ria_ora_tests` add in datalad#669, and was discovered by Debian's CI Thanks to @aqw for the recommendation. Closes: datalad#698 Refs: datalad#669, https://ci.debian.net/packages/d/datalad-next/testing/amd64/46884776/
Since 1.4.0 a plain `datalad_next` import required `pytest`. This was due to the datalad-core patch `fix_ria_ora_tests` added in datalad#669, and was discovered by Debian's CI Thanks to @aqw for the recommendation. Closes: datalad#698 Refs: datalad#669, https://ci.debian.net/packages/d/datalad-next/testing/amd64/46884776/
Since 1.4.0 a plain `datalad_next` import required `pytest`. This was due to the datalad-core patch `fix_ria_ora_tests` added in datalad#669, and was discovered by Debian's CI Thanks to @aqw for the recommendation. Closes: datalad#698 Refs: datalad#669, https://ci.debian.net/packages/d/datalad-next/testing/amd64/46884776/
This PR addresses the issues with Windows-clients that use RIA-stores. It replaces the classes
datalad.distributed.ora_remote.ORARemote
anddatalad.distributed.create_sibling_ria.CreateSiblingRia
with updated versions that should work properly on Linux, OSX, and Windows.What does it do?
The main difference to the original code is that all path-operations, e.g. to determine the location of
ria-layout-version
, are performed on URL-paths. Those are represented by instances ofPurePosixPath
. All subclasses ofBaseIO
, i.e.LocalIO
,SSHRemoteIO
, andHTTPRemoteIO
, are extended to contain the methodurl2transport_path
. This method converts an URL-path into the correct path for the respective IO abstraction.Before methods on a subclass of
BaseIO
that require a path are called, the generic URL-path is converted into the correct path for the IO-class by callingurl2transport_path
on the respective IO-class.A number of tests had to be adapted because the patched methods now assert the correct type for the abstract paths, i.e.
PurePosixPath
. This assertion made several tests fail because they provided OS-paths.The PR keeps changes to the necessary minimum. That means the source is mostly identical to the original, except for the changes described above.
TODO