Better distinguish # via [current project] comment

[oprypin]

Hi!
I was just looking at the latest lock file in my env.

It had this entry, for example

markdown-callouts==0.3.0
    # via mkdocs-literate-nav

where "mkdocs-literate-nav" is the current project's name. But I was very confused - this detached env shouldn't be depending on the project itself, and mkdocs-literate-nav is not written as a dependency in it anywhere.
So I started debugging why there's a dependency.

But actually there isn't a dependency! # via [current project] just stands for "specified in pyproject.toml"

Before this change it was at least # via [current project] (pyproject.toml) and that was quite a bit clearer.
https://github.com/juftin/hatch-pip-compile/pull/9/files#diff-a17e936862775c98a1a6459602e69226471d05e2d151d52b61a73d80a54e86d0L165
I think I'd like to get back that extra clarification.

Here's what pip-compile itself shows normally:

markdown-callouts==0.3.0
    # via -r requirements/requirements-docs.in

The project's name is not mentioned and that makes a lot more sense.

I think the line should become something like # via pyproject.toml (docs). Although I suppose the config doesn't even have to be in pyproject.toml, maybe it's hatch.toml, so not so obvious...

[juftin]

Yeah I removed the project.toml part of it because I didn't have a clean way to tell whether the config was coming via pyproject.toml or hatch.toml.

Do you happen to know if there are easy ways to discern where the config is set?

[oprypin]

I'm guessing there isn't a way to determine that. It looks to be merged without a trace.
https://github.com/pypa/hatch/blob/d666ae7b3dacded86faa96cc0454bb1e69132dc7/backend/src/hatchling/metadata/core.py#L206

I think it's acceptable to not mention that it's pyproject.toml. But I'm mainly saying that mentioning the project name is misleading.

[oprypin]

Could be # via Hatch 'docs' env
or maybe # via tool.hatch.envs.docs

[juftin]

Could be # via Hatch 'docs' env
or maybe # via tool.hatch.envs.docs

# via hatch.envs.docs sounds like a winner to me.

How do you feel about # via hatch.envs.default though?

[oprypin]

What do you mean? # via hatch.envs.default is good, if the env is default :)

[oprypin]

Easy change in the code btw 😁

-            f"{self.metadata.name}",
+            f"hatch.envs.{self.name}",

[juftin]

What do you mean? # via hatch.envs.default is good, if the env is default :)

I was thinking of a situation where the default env would get the # via {self.metadata.name} while non-default envs would get # via hatch.envs.{self.name}

But, I think you're right. Just staying consistent with hatch.envs.{self.name} is the most clear

[juftin]

🎉 This issue has been resolved in version 1.0.2 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀