"the project is used by the project" is possibly the most confusing statement I've ever seen.

Thanks for clarifying this point. I didn't realize this behavior was available.

For build dependencies this might change in the future, so not sure if we should state it in the docs.

My understanding was that in #3768 we decided the best idea would be to add an include deptype for things that affect the hash but can be uninstalled after installation.

Anyway, based on how long #3768 has been sitting without any changes, I would rather document the current behavior than document some future behavior.

My understanding was that in #3768 we decided the best idea would be to add an include deptype for things that affect the hash but can be uninstalled after installation.

@adamjstewart The dependency model discussed in #3768 is outdated in the sense that:

1. A build dependency might affect how a package binary is built, so it should affect the hash since we use that for reproducibility (think of a cmake that changes some compilation defaults across versions)
2. There are other aspects to be taken into consideration, for instance if a dependency is unified over a DAG or not (one can build 10 different nodes of a DAG with 10 different cmake, but likely can't use different versions of the same C++ template library in a single DAG)

I concur that what is documented here is the current implementation and I'm fine with these changes overall. Can we maybe add a note or warning box to state that we might change how build deps affect the hash in the future if extending some aspect of the dependency model require it?

1. I don't want to think about this 😦 . I agree it could be problematic, but having the build dep affect the hash will cause a lot of reinstalls. I guess we'll probably wait until the new concretizer for that so there are fewer rebuilds.
2. I would argue that such a C++ template library should be a type=link or type=include dependency, but I don't know as much about C++ so maybe I'm wrong.

I'll wait for one more reviewer to suggest adding a note about how these might change in the future. I'm trying to be as detailed as possible without confusing the reader. I assume if we change the behavior of any of these deptypes, we will update any packages that need to be updated accordingly. So it's not as important (to me at least) to warn users of future behavior in the Packaging Guide.

I guess we'll probably wait until the new concretizer for that so there are fewer rebuilds.

That's in fact the first use case I have in mind. Fine with me to wait for other reviewers and see what they think.

I'll wait for one more reviewer to suggest adding a note about how these might change in the future. I'm trying to be as detailed as possible without confusing the reader.

Just to be explicit on my intent and avoid misunderstanding: I'm not proposing to document now how things will change, but just suggesting to add a brief note to users to say that the behavior of build deps might still change in the future.

I think documenting the current behavior and changing the documentation as needed is the proper course of action.