Initial setup

[CodyCBakerPhD]

Starting initial work on this since I needed a special extension for the Leifer lab and their electrically tunable lens (variable depth)

[CodyCBakerPhD]

WDYT @alessandratrapani?

Tests are passing, should we get this in to serve as a base for further improvement?

[CodyCBakerPhD]

BTW @rly

If I uncomment this part it errors out at io.write

    @docval({"name": "spec", "type": Spec, "doc": "the spec to get the attribute value for"},
            {"name": "container", "type": AbstractContainer, "doc": "the container to get the attribute value from"},
            {"name": "manager", "type": BuildManager, "doc": "the BuildManager used for managing this build"},
            returns='the value of the attribute')
    def get_attr_value(self, **kwargs):
        ''' Get the value of the attribute corresponding to this spec from the given container '''
        spec, container, manager = getargs('spec', 'container', 'manager', kwargs)
        attr_name = self.get_attribute(spec)
        if attr_name is None:
            return None
        attr_val = self.__get_override_attr(attr_name, container, manager)
        if attr_val is None:
            try:
>               attr_val = getattr(container, attr_name)
E               AttributeError: 'PlanarImagingSpace' object has no attribute 'grid_spacing__unit'

Any idea what's going on there?

What's especially odd is the origin_coordinates follows the same exact pattern but works fine

[rly]

Thanks for the ping. This is an issue with HDMF that we haven't encountered before. I filed an issue here hdmf-dev/hdmf#1121 and created a fix here hdmf-dev/hdmf#1122.

I'll aim for a quick bugfix release early this week. Then grid_spacing__unit should work.

That said, I was thinking about the "unit" attribute for the ProbeModel.planar_contour argument in ndx-extracellular-channels. That is a set of coordinates that needs units too. I removed the ability of the user to set the unit, and changed planar_contour to planar_contour_in_um. I think there is little value in having the user set the unit. As per some of our recent discussions at the dev hackathon and before, data producers often just want to be told what to do to standardize their data, and software tools and data reusers have a hard time working with data that is too variable across datasets, e.g., when the names of the same kinds of objects differ across datasets for no good reason.

It's probably good to have the unit field and fix it to micrometers. By fixing it to that value, we can add _in_um to the name for extra clarity.

Just my two cents!

[CodyCBakerPhD]

I think I agree - let's do this in a small follow-up

[rly]

This file should be removed. Using the latest ndx-template, which I think you used here, this was replaced by pyproject.toml. The problem with this setup.py is that it copies the spec folder into /src/pynwb/ on install, and so if you make changes to /spec/ndx-microscopy.extensions.yaml, you might expect the changes to be reflected in your environment, but no, the cached yaml in /src/pynwb/spec/ is used instead.

[CodyCBakerPhD]

Makes sense - we'll deal with it in a follow-up since the way I copied this base didn't have the hatchling stuff in the TOML

[alessandratrapani]

Ok