Handle the situation of installing the project without a tag

[candleindark]

versioningit, the versioning system, requires at one tag in the repo to work. If a new user trying out DL-Registry by forking it on GitHub without copying any tag, he/she may experience an error in setting up the project through the fork. Note about the handling of such a situation in the documentation or set up automatic version through another mechanism (such as automatic versioning through poetry version once #329 is complete).

[jwodder]

One option for handling this is to specify a tool.versioningit.vcs.default-tag value in pyproject.toml (docs here).

[yarikoptic]

can we just describe in our deployment documentation that need to have a tag or use a proper export/release on pypi?

[candleindark]

can we just describe in our deployment documentation that need to have a tag or use a proper export/release on pypi?

I can, but I feel that doing this make the setup process less intuitive and making our project seems less polished. We can consider adding this information as a "footnote" in the documentation, without interfering with the flow of the setup instruction.

I think having a default tag as recommended by @jwodder is a better way to go. After all, we can't really ensure, if my limited understanding of versioningit is correct, that the version of DL-Registry built by a user will be based on the tags in the datalad/datalad-registry repo. A user can add a new tag to their clone of the DL-Registry repo and knowingly or unknowingly have the version number of their build of DL-Registry based on that tag. IMHO, what we should aim to achieve in matter is to allow anyone who is interested in the project to set it up easily, without any error or much configuration. Providing a default tag seems to achieve just that.

@yarikoptic I am not aware that we currently have any release for DL-Registry on pypi.

[yarikoptic]

• we should have release on pypi. Ideally releases should be automated, likely via https://github.com/datalad/release-action
• IMHO failing to install from an incomplete "source" (either export to pypi or properly tagged git repo) is better than someone later coming with a report about some unknown "default" version of software. Having default tag is IMHO just hiding a potential problem "until later".
• AFAIK we have been using @jwodder 's versioningit without needing for a "default-tag" in other repos, I do not see why we would need it here

[candleindark]

• we should have release on pypi. Ideally releases should be automated, likely via https://github.com/datalad/release-action

I filed #336 to follow up with this matter.

• IMHO failing to install from an incomplete "source" (either export to pypi or properly tagged git repo) is better than someone later coming with a report about some unknown "default" version of software. Having default tag is IMHO just hiding a potential problem "until later".

Though I don't like to see anyone encounter an error while installing the project, I see your point. Consistency does have its cost, and this is a good occasion to pay for it. I have made some addition to README.md to close this issue.