Accessing Project from Job

[javierbg]

Feature description

Sometimes I need to access the Project object from a job, for example to access the project-wide data attribute. Currently, in order to achieve this, a module-wide variable has to be created for the project, but this could span out over several modules and need to load/import the project from each one.

Proposed solution

Exposing the already present job._project as job.project. If this is not possible in the near future, the current way of doing things could be explained in the docs (I was not able to find it, if it is not there I could add it myself).

[csadorf]

@javierbg Thank you for reporting! 👍

[bdice]

@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 changed this currently, but for most cases job._project will provide the project that you want. The project developers have had several discussions in the past about the project/job relationship, not all of which are documented on GitHub. We would likely make this change in signac 2.0 depending on the outcomes of some relevant issues like #390, #96. Feel free to join our Slack community if you want to learn more, contribute to the package, or discuss this issue during a developer meeting! 😃 https://signac.io/slack-invite/

[tcmoore3]

See also #96

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[vyasr]

@glotzerlab/signac-committers should we revisit this going into signac 2.0? It would be possible to change this now, does anyone see any downsides?

[bdice]

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.)

[b-butler]

I personally use job._project in my projects for things like project default values.

[cbkerr]

I can see another use case: saving a plot from an aggregate back to the project directory for display using the dashboard project overview.

[bdice]

Awesome. Here is a proposal for implementation:

1. On the next branch, edit signac/contrib/job.py to include the following:

@property
def project(self):
    """Return the project that contains this job."""
    return self._project

2. Add tests to ensure that the project is what we expect, and that the project attribute cannot be assigned (should raise).
3. Add the project property to the documentation.

As an extension of this proposal, we could make assignment of the project property trigger a “move” of the job. We could do that by adding a setter, and we already have methods to move jobs from one project to another that handle the project cache invalidation correctly. We would also have to invalidate the job’s cached properties.

I’ll label this a good first issue since I don’t anticipate any major design challenges in the first portion of the implementation proposal for the property.

[vyasr]

The only change I would make to the above instructions is that we'll want to branch off of schema2, not next (or wait for schema2 to be merged into next). As long as the workspace directory is configurable the job->project mapping isn't quite valid.

While I am still in favor of this, and all the necessary upstream changes have now been made to enable this feature, I do not think this is a blocker for 2.0. This is a nice-to-have feature, but it's not critical and there's no reason that it couldn't be added in a minor release. Especially since we've marked it as a good first issue I would like to leave it available rather than pushing to complete it for 2.0

[bdice]

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

[vyasr]

Resolved by #808.