Develop Context class

[ubdbra001]

closes #32 (eventually)

I'm happy to leave this open and just add to it as I approach the rest of the methods, but if you'd like to open a PR for each of the rest of the methods then I'm also happy to defer to you on that.

Here's my initial attempt at this:

• I've developed the low-hanging fruit for Context (path, entities, datatype, suffix, extension, modality, and size) and added stubs for the rest
• I've also added tests for the methods developed

One thing I wasn't sure about is where it would be beneficial to use cached_property over property for this class (and I suppose more generally). Any advice?

My next step will be to develop the subjects method along with the Sessions class. I think I'll start by creating test for these (so you can make sure I understand how these are meant to work) and then go from there.

[codecov]

Codecov Report

❌ Patch coverage is 92.01878% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.95%. Comparing base (51450b3) to head (88ce2e5).
⚠️ Report is 38 commits behind head on main.

Files with missing lines	Patch %	Lines
src/bids_validator/context.py	85.43%	12 Missing and 3 partials ⚠️
src/bids_validator/types/files.py	89.47%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #34      +/-   ##
==========================================
+ Coverage   89.68%   90.95%   +1.27%     
==========================================
  Files          12       12              
  Lines         630      774     +144     
  Branches      104       87      -17     
==========================================
+ Hits          565      704     +139     
- Misses         42       46       +4     
- Partials       23       24       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[effigies]

Cool. A couple quick notes.

[ubdbra001]

I just added the tests for the subject method and Sessions class. Do they make sense? Am I missing anything?

[effigies]

Makes sense to me. I would just skip sessions.phenotype. That's been removed in the latest version of BIDS, since it was never used.

[ubdbra001]

Started playing around with this and I'm using the walk_back function to work backwards from the specific file in Context to get the tree for the subject entity.

1. Does this make sense?
2. If yes, the walk_back / _walk_back function throws an error because FileParts now expects schema to be passed (Line 249). Shall I just update this so that schema is passed to walk_back? Or do you have a better suggestion?

[effigies]

I would actually probably create subject once when entering a subject directory, and then pass Context(dataset, subject, file) on each file inside it.

def walk(directory, dataset, subject=None):
    if subject is None and is_subject_dir(directory):
        subject = Subject(directory, dataset)

    for child in directory.children:
        yield Context(child, dataset, subject)
        if child.is_dir():
            yield from walk(child, dataset, subject)

tree = FileTree.read_from_filesystem(root)
dataset = Dataset(root, schema)
for context in walk(tree, dataset):
    ...

[ubdbra001]

Right, that does make sense. This should be in __main__.py where we're starting walking through the FileTree from the root directory?
Is this the only part of the context that would benefit from earlier creation it earlier in the walk and then passing it to the Context object?
Looking at the list in #32 I don't think so, but I thought it would be worth double checking.

[ubdbra001]

Also, am I right in thinking that we'll still be using the walk_back functions for the sidecar? And if so we'll still need to fix up those functions to pass schema on?

[effigies]

This should be in __main__.py where we're starting walking through the FileTree from the root directory?

Yes, or wherever we do the walk.

Is this the only part of the context that would benefit from earlier creation it earlier in the walk and then passing it to the Context object?

Yes, Dataset and Subject are the only two.

Also, am I right in thinking that we'll still be using the walk_back functions for the sidecar?

Yes.

And if so we'll still need to fix up those functions to pass schema on?

Seems excessive. What do you think about making schema optional and just leaving datatype as None if schema is not passed?

[effigies]

A couple notes.

[ubdbra001]

I ended up using a load_sidecar function because it made for a simpler test to check that inheritance is working properly.
I've started testing more files to capture the different behaviours (e.g. file that doesn't have a sidecar, etc), it seems a bit messy to me so any guidance on how best to tidy it would be welcome.

[effigies]

We've tied ourselves pretty tightly to the filesystem here, which makes mocking up objects difficult, as well as anything where we won't have access to directory entries, like datasets in the cloud.

I think it probably makes sense to wrap a Path | UPath instead DirEntry, and limit ourselves to the Path API.

I think we could then create mock files for testing by subclassing UPath to provide things like read_bytes() and is_dir().

class TestPath(UPath):
    def __init__(path, contents):
        self._contents = contents

    def read_bytes(self):
        return self._contents

Or possibly we end up with a TestTree that generates Path-like objects on demand.

tree = TestTree({
  '/bold.json': json.dumps({'RepetitionTime': 2}).encode(),
  ...
})

[effigies]

Resetting to draft, pending columns implementation.

[effigies]

Made a PR against your PR: ubdbra001#1

Can factor it out, if you prefer. It's mostly orthogonal.

[ubdbra001]

I've added the code for the columns property. I also added some tests, but: 1. these are still using the file system, and 2. (related) the contents of the tar.gz files is quite large, and I didn't get a chance to think about how to deal with this.
Addressing 1 and creating some smaller test files in memory would address 2, but I think that may be worth doing separately as an overhaul for the current context.py test file