Bradley Dice

@mikemhenry Is this targeting 1.x or 2.x (`next`)?

> Do we continue doing that and simply rename the package to `_synced_collection` Yes. We will expose the `BufferedJSONAttrDict` class from that package in the public API, but `signac.synced_collections` will...

@javierbg I agree this feature would be useful and we may implement it as you described in signac 2.0. There are some edge cases that could be problematic if we...

I have spent some time thinking about this and can’t think of any downsides. I propose the project property is purposefully public, prior to publishing post-1.x packages. (Alliteration is fun.)

Awesome. Here is a proposal for implementation: 1. On the `next` branch, edit `signac/contrib/job.py` to include the following: ```python @property def project(self): """Return the project that contains this job.""" return...

Following up: `schema2` has been merged into `next`, so this work should begin from the `next` branch.

I think the behavior is fine, and it's more consistent with the removal of `groupbydoc`. We document this behavior: > If _key_ is None, jobs are grouped by id, placing...

The most obvious behavioral difference I see is that `groupbydoc("nonexistent_key")` raises but `groupby("nonexistent_key")` does not raise, because signac filters to only jobs where the key exists in `groupby` but not...

To concretely answer @cbkerr's questions above (partially repeating previous comments for clarity): > This leads me to wonder if the sp query namespace should also raise a KeyError I don't...

I think the right place to put this is below this line: https://github.com/glotzerlab/signac/blob/aed17f324b3e1f5dfb3328cff6c2ab73ca434929/signac/common/config.py#L147 I think it should say: ```python def load_config(root=None, local=False): """Load configuration, searching upward from a root path."""...