Modernize metadata

[ofek]

This fixes #4337 (comment) by implementing the workaround that other large projects have chosen after removing their setup.py:

• https://github.com/pallets/flask/blob/main/setup.py
• https://github.com/urllib3/urllib3/blob/main/setup.py
• https://github.com/encode/httpx/blob/master/setup.py

[ofek]

The "Used By" will repopulate within a few days

[squidfunk]

Okay, great, thanks! I'll revisit this PR after the blog plugin is out and the dust has settled. Doing two things at once often doesn't pan out great 😉

[ofek]

Cool! Is blogging public or insiders?

[squidfunk]

The blog plugin will be first released in Insiders, exclusively to sponsors. It's the biggest release this year and it's a great feature to convince more users to support the project by funding it to help make it even better 😊

[ofek]

"Used By" is back already fyi

the biggest release this year and it's a great feature

Yup this will be the first time I'll be forced to stop being lazy and set up Insiders! I've just been sponsoring and waiting for many things.

[squidfunk]

Ah, hehe, thanks for sponsoring anyway then! I think you'll enjoy using Insiders, as it comes with several niceties.

[squidfunk]

Could you please update the PR to include the social plugin? It was released as part of 8.5.0.

[ofek]

Done!

[squidfunk]

Thanks! One final question: Does pip install -e . still work with the proposed changes? I'm using this for development + users need to pip install . when they install from git. Otherwise, the documentation needs to be updated as well.

[ofek]

Yup, PEP 660 (-e) landed in https://pip.pypa.io/en/stable/news/#v21-3

[squidfunk]

Okay perfect. Let's give it another try. Thanks again for your patience!

[squidfunk]

@ofek we're having an issue with Insiders. The Node.js plugin doesn't allow for local version identifiers:

This means that Insiders can currently not be installed. I need to revert this again for Insiders.

[ofek]

cc @agoose77

[agoose77]

@squidfunk this error stems from the fact that currently hatch-nodejs-version doesn't support local identifiers. This was a design choice, so that NPM and PEP440 versions could round-trip. However, I might have made a mistake here - I think both "local" (PEP440) and build (NPM) do not affect version resolution, and are defined by the same regex. I'll make a new release to address this oversight.

[squidfunk]

@agoose77 perfect, thanks for the quick response!

[agoose77]

Ah OK, I recall why I made this choice - In Python, local version segments are considered for comparison, whereas in npm they (build segments) are entirely ignored. I suppose that we might allow this, as long as users are aware of the differences.

[ofek]

Add an option?

[agoose77]

I've released a new version (0.3.0) of the hatchling plugin that should fix this issue according to @ofek

You should change the metadata to reflect this version as a lower bound (hatch-nodejs-version >= 0.3.0)

[Kludex]

@ofek What does it mean for the dependencies to be dynamic?

mkdocs-material needs to depend on mkdocs>=1.4.0, but the installation doesn't ensure this. Is it because of the pip version, or is there something wrong here?

[agoose77]

@Kludex I can answer in part. Any field in pyproject.toml (besides name) can be dynamic, and it simply means that the build backend (e.g. hatchling) will provide this metadata: https://peps.python.org/pep-0621/#dynamic. My understanding is that the dynamic field itself is not directly used by PEP 517 frontends, rather it is useful for tools to know whether to ask the backend for metadata rather than just using the pyproject.toml file. @ofek might correct me here, though.

[agoose77]

The pyproject.toml file has dependencies set to dynamic, because the requirements_txt hook populates the depedencies metadata using https://github.com/squidfunk/mkdocs-material/blob/master/requirements.txt