`read-manifest`: distinction for workspace manifest

[secona]

The current implementation of read-manifest outputs all manifests under ReadManifestOut::Manifest. This makes it difficult to get the workspace manifest out of a series of manifests.

See #78 (comment)

[secona]

I've given this some thought. I feel like the options are either

  {
    "manifest": {  },
    "path": "[ROOT]/foo/Cargo.toml",
    "pkg_id": "path+[ROOTURL]/foo#read-manifest-test@0.1.0",
    "reason": "manifest",
    "root": true
  }

or

  {
    "manifest": {  },
    "path": "[ROOT]/foo/Cargo.toml",
    "pkg_id": "path+[ROOTURL]/foo#read-manifest-test@0.1.0",
    "reason": "root-manifest"
  }

Thoughts?

In practice, I think read-manifest would always output one root-variant manifest message.

[epage]

I worry root could be confusing. Just workspace?

Or can't we check which manifest has a workspace table?

Hmm, but other steps may need to know the workspace while needing non-workspace members loaded and not all workspaces have a workspace table. At that point, we'll likely also need to know workspace members from path deps.

[secona]

I worry root could be confusing. Just workspace?

Or can't we check which manifest has a workspace table?

I'm not sure that'd work with non workspace packages (as in simple packages where there's only one manifest file).

My idea of having a root "marker" is that its a pointer to where the lockfile is located. Users can .join("Cargo.lock") to get the expected path of the lockfile without any overhead. During read-manifest execution, we know which message "marks" the lockfile path. We just don't tell users which message it is.

Hmm, but other steps may need to know the workspace while needing non-workspace members loaded and not all workspaces have a workspace table. At that point, we'll likely also need to know workspace members from path deps.

Which steps would that be?

[epage]

Or can't we check which manifest has a workspace table?

I'm not sure that'd work with non workspace packages (as in simple packages where there's only one manifest file).

Sorry, i left a step out. The idea is that if we only return workspace members,

• 1 workspace member: must be workspace root
• N workspace members: check workspace table

My idea of having a root "marker" is that its a pointer to where the lockfile is located. Users can .join("Cargo.lock") to get the expected path of the lockfile without any overhead. During read-manifest execution, we know which message "marks" the lockfile path. We just don't tell users which message it is.

I feel I'm missing soemthing in whats being communicated here.

Hmm, but other steps may need to know the workspace while needing non-workspace members loaded and not all workspaces have a workspace table. At that point, we'll likely also need to know workspace members from path deps.

Which steps would that be?

iiuc read-lockfile has to do lookups for all path-dependencies, not just workspace members.

[secona]

My idea of having a root "marker" is that its a pointer to where the lockfile is located. Users can .join("Cargo.lock") to get the expected path of the lockfile without any overhead. During read-manifest execution, we know which message "marks" the lockfile path. We just don't tell users which message it is.

I feel I'm missing soemthing in whats being communicated here.

From my understanding, the lockfile path is relative to the workspace manifest. During read-manifest execution, we know which manifest that is, we just don't explicitly say that it is.

Hmm, but other steps may need to know the workspace while needing non-workspace members loaded and not all workspaces have a workspace table. At that point, we'll likely also need to know workspace members from path deps.

Which steps would that be?

iiuc read-lockfile has to do lookups for all path-dependencies, not just workspace members.

read-lockfile, currently, only reads a Cargo.lock and normalizes it into messages. Its not until lock-dependencies that we're doing lookups for path deps.

[epage]

From my understanding, the lockfile path is relative to the workspace manifest. During read-manifest execution, we know which manifest that is, we just don't explicitly say that it is.

Talk of a "pointer" made it sound like something other than what I'd term a marker (workspace: true)

[secona]

I've opened #94 to make it clearer for further discussions. I've only implemented things that I'm sure of.

[epage]

I've only implemented things that I'm sure of.

What was then not implemented? Are there reasons its a draft?

[secona]

I've only implemented things that I'm sure of.

What was then not implemented? Are there reasons its a draft?

I wasn't sure if there were changes missing from the PR, which is why I made it into a draft first.

Now I just realized that I haven't updated the check example.