Disallow direct references for dependency definitions

[ofek]

No description provided.

[hashstat]

So we just made the switch to hatchling and had our build pipeline running without any issues for a couple of days before hatchling 0.20.1 was released and this change introduced. And now our builds are breaking because we make use of a direct reference.

We currently maintain a fork of koala2, with updates that haven't been merged into the upstream project and likely will not be merged because the maintainer has abandoned the project. We are using this updated koala2 in a project that is not published to PyPI, but is only distributed internally, and using direct references has eased the burden of including koala2 by simplifying building, configuration, and installation.

I understand why direct references shouldn't be used for public packages indexes. But is there any harm in allowing their use in private projects? Would you be open to a PR that would allow direct references again, provided an option is set in pyproject.toml or maybe when an environment variable is set?

[ofek]

Hey! What about based on pypi/warehouse#5440?

[hashstat]

Hey! What about based on pypa/warehouse#5440?

That is a fantastic idea for preventing our package from being accidentally added to PyPI. I will definitely add the Private classifier to our package.

I suppose using the Private classifier to silence the direct references error is also an option, but I'm not really a fan of it for the following reasons:

1. Trove classifiers are primarily designed as filtering criteria on PyPI. PyPI is the intended end user of that metadata. I haven't seen it used elsewhere to control how packages are built, nor would I expect that
2. Currently, hatchling only appears to check that classifiers are unique. It doesn't process them in any other way. Using the classifier to control the error would now require some processing of classifiers which are not meant for hatchling
3. I expect there are other users with private projects who might want the builds to continue to fail when direct references are used. So using a more explicit control is desirable

All of the above problems are fixed by using pyproject.toml to configure if the error should be raised. My suggestion is to add an 'allow-direct-references' option that could be used in the tool.hatch.build, tool.hatch.build.targets.sdist, and tool.hatch.build.targets.wheel sections. It would default to false to provide the current behavior of raising an exception when a direct reference is provided, but allow direct references if set to true.

What do you think, @ofek?