Make ITK keywords in PyPI consistent

[jhlegarreta]

Description

ITK-related keywords across PyPI packages (e.g. remotes, etc.) are not consistent: some use uppercase (ITK), some lowercase (itk), some have InsightToolkit from pre-cookiecutter days, etc.

Also, some short descriptions:

• End with a period, others do not, etc.
• Start with a seemingly unnecessary An ITK remote module (...), etc.

Expected information

Make:

• All keywords consistent.
• All descriptions consistent and accurate.

Actual information

ITK-related packages in PyPI have inconsistent keywords and descriptions.

Versions

N/A.

Additional Information

None.

[aaliyahnl]

working on this :)

[aaliyahnl]

#4854

[jhlegarreta]

#4854

Unfortunately, this is not what it is expected and indeed changing the names of the released compressed files does not make much sense, so I will go ahead and close the PR.

Here, we are talking about the remote repositories, and the keywords any Python package has across the PyPI package index.

@aaliyahnl if you are still willing to work on this, take a look at the remote repositories, their Python configuration files, and the keywords across packages in PyPI.

Also, we should agree here on the convention to be used (lowercase vs uppercase ITK, the wording for the descriptions, etc.).

[aaliyahnl]

Willing, but not sure where these files are found. Could I get an example of an inconsistent mention of ITK? Thanks!

[jhlegarreta]

Willing

Great, thanks.

but not sure where these files are found. Could I get an example of an inconsistent mention of ITK? Thanks!

ITK remotes are a collection of repositories that contain ITK modules that are developed independently with the promise that they will be eventually merged into the ITK code base. We may need to do a better job documenting the remotes across our resources, e.g.:
https://docs.itk.org/en/latest/index.html
https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Remote/README.md

Some issues have been opened related to remotes, e g.:
#4786

Which was opened due to the time I spent gathering all known remotes and others that were less known in:
#4748

So each remote has a pyproject.toml Python configuration file that has a Keywords dictionary entry. This issue is about these keywords, e g.
https://github.com/InsightSoftwareConsortium/ITKAnalyzeObjectMap/blob/main/pyproject.toml#L14-L17
https://github.com/InsightSoftwareConsortium/ITKAnisotropicDiffusionLBR/blob/main/pyproject.toml#L14-L16
https://github.com/slicersalt/ITKShape/pull/30/files#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711R14-R17

Those keywords are used by the Python packaging system and are eventually used when the package is released into the Python Packaing Index (PyPI), e.g. (check for the tag icon under the Meta section)
https://pypi.org/search/?q=itk-remote&o=
https://pypi.org/project/itk-anisotropicdiffusionlbr/
https://pypi.org/project/itk-shape/

(Some of the remotes have not been made available to PyPI)

So we should be consistent and comprehensive when adding keywords to the ITK remotes.

Some remotes only have ITK or InsightToolkit as their keywords, which is poor.

Eventually, ideally, they should be used to describe the repositories in GitHub as well.

[jhlegarreta]

To complete the description above, some of the ITK remotes, those that dwell in the Remote directory
https://github.com/InsightSoftwareConsortium/ITK/tree/master/Modules/Remote

can be checked out when building ITK and if the corresponding CMake flags are set to ON. Changes to those modules can be directly committed to the corresponding repositories.

The ITK Utilities module has a some shell scripts that facilitate maintenance of the modules:
https://github.com/InsightSoftwareConsortium/ITK/tree/master/Utilities/Maintenance

• ApplyScriptToRemotes.sh
• UpdateRequiredITKVersionInRemoteModules.sh

They have not received a lot of updates lately

The other path is to checkout each remote into a different path, apply the changes and commit and push them. Matt has recently used this tool to apply changes without too much effort across a number of repositories:
https://github.com/asottile/all-repos

And using some scripting and git CLI would also allow to accomplish these tasks investing less time. We should improve the automation of these tasks.