ENH: import datalad.api to bind extensions methods for discovery of dataset methods#5999
Conversation
…ataset methods This might be not the most elegant but the "easiest" in DX approach to resolve this issue IMHO. It might cause run time penalty though in small scripts which import only a few dedicated modules, thus do not require import of the entire API. An alternative would be to e.g. do 2 rounds of that loop, importing datalad.api only upon the end of the first loop if no meth is found. Closes datalad#5990
Codecov Report
@@ Coverage Diff @@
## maint #5999 +/- ##
==========================================
- Coverage 90.27% 88.04% -2.23%
==========================================
Files 308 305 -3
Lines 42116 42085 -31
==========================================
- Hits 38021 37055 -966
- Misses 4095 5030 +935
Continue to review full report at Codecov.
|
|
crawler issue is unrelated. filed datalad/datalad-crawler#104 |
import of datalad.api already causes all the binds to happen. That would eliminate the need for duplicate code for binding them within __getattr__
mih
left a comment
mih
left a comment
There was a problem hiding this comment.
OK, let's do this. However, I want to put on record that I believe we might end up revisiting this. More extensions, will ultimately require more careful, less unconditional importing to avoid uncontrolled slowdown. But for now the reduced complexity is attractive!
|
Travis issue seems unrelated. |
2 participants
This might be not the most elegant but the "easiest" in DX approach to resolve
this issue IMHO. It might cause run time penalty though in small scripts which
import only a few dedicated modules, thus do not require import of the entire
API.
An alternative would be to e.g. do 2 rounds of that loop, importing datalad.api
only upon the end of the first loop if no meth is found.
Closes #5990