Removing signac project id

[vyasr]

I've been meaning to raise this question for a while, and in anticipation of resolving #527 I think now is a good time to consider it: should we remove the project name in signac schema version 2? Currently we use it sparingly, pretty much just to provide a string representation of a project and in associated functions like naming a temporary project. signac-flow uses this to generate the unique submission id, but the fact that a project name is not guaranteed to be unique anyway forced us to add the project directory to the submission id hash anyway. We can always introduce alternative methods in signac-flow's FlowProject to give more meaningfully named submissions, if the main value is that a submitted cluster job can be associated with a project based on the name. Is there any other meaningful upside to keeping this, rather than just falling back to the name of the current directory? I think it's worth considering as part of the shift, especially since we're removing workspace configurability.

[bdice]

When copying/moving projects between machines, the project name helps to differentiate between projects that might otherwise only be distinguished by their filesystem path. Also the project name definitely helps me manage my cluster jobs because a user-readable snippet of the project name is in the beginning of the signac-flow submitted job name (though it is insufficient for unique identification as mentioned above).

I don't see a huge benefit to removing the name. I think it's a helpful option for archival purposes and having a name gives some important insight about the project contents to users who are given data on a filesystem and have no prior experience with signac. If other developers felt strongly that this should be removed, I would argue for adding a default configuration value; I would settle for not requiring a name.

[vyasr]

Regarding the cluster jobs, while I see the utility I think it's misplaced. It would be more appropriate to use the name of the FlowProject subclass to identify submissions, not the signac project. Submission-related logic (including conveniences like naming) belong in flow, not signac. We could revisit that renaming as part of the ongoing schema refactorings.

I would also settle for making a name optional. I frequently get annoyed when doing signac init because I forget to provide a name (I don't find them useful and always forget to create projects with them). However, I do see the value in archival purposes. I see a project name as something that should be optional metadata, but not something that should be required.

[bdice]

Re: FlowProject name, we might want to update our examples to show that in practice, like class IdealGasProject(FlowProject):. Otherwise that is a good idea.

Suggestions for a default name value? Project?

[csadorf]

I am in favor of removing it or – if we want to keep it – to use it as some well-defined, but optional, project metadata. In that case we should also consider to support other metadata, like author(s) and copyright, etc.

[vyasr]

At the signac dev meeting today we had pretty much unanimous approval for removing the project id. We want a clean separation between signac's internal data and user-facing metadata, so the config is not the correct place be storing this. A couple of options for future improvement:

1. We can encourage users to create a README.md on signac init
2. We could add a new "state point" file to projects, something like project-description.toml that could support some set of standard metadata.

Both options are independent of this issue and could be handled subsequently if interested, but removal of the signac id should not be contingent on implementing them.

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

[cbkerr]

I often store several "projects" that could be initialized in my init.py, picking via a command line option.

Each project has different sets of relevant state points (eg for different figures that all run the same code). Putting them all in one project could make it harder to filter or work with the jobs. Currently, I use the project id to prevent me from initializing a different project with its corresponding different cross section of jobs. What's a way to replace this use case?

EDIT: If directory names are replacing this guess I just pass in different root directories and my directory structure would become:

/projects/fig1/
               signac.rc
               workspace
/projects/fig2/
               signac.rc
               workspace
/src/init.py
     project.py