Reasoning behind __about__.py for metadata

[cdwilson]

Just curious, what is the reason for defaulting to using a separate __about__.py for storing the __version__ metadata? (vs. just including __version__ and other metadata in __init__.py)

(I'm new to python/hatch and I figured there is a good reason for this, but I just don't know the context)

[ofek]

Don't wanna clutter what's available to import at the root

[lwasser]

hey there @ofek 👋 we were wondering about this too over at pyOpenSci. i'm actually creating a video about making the most basic version of a package / installable code using hatch. but i had a hard time explaining what that about.py file really was. in our community no one has heard of it. is it a standard somewhere? AND if not, is there a way to tell hatch to not include it in the config ?for a beginner, it feels like an additional file to think about that is not well documented / understood in our community

many thanks for your thoughts!

[ofek]

I can remove it if you want from the template and use __init__.py exclusively but the current way matches what one would do for persisting version metadata when it comes from VCS like Git. See https://github.com/ofek/hatch-vcs

[lwasser]

hi there @ofek . Please know that I don't want to dictate what direction or opinion hatch takes. BUT, when we discussed it in our scientific community, no one was familiar with the about.py file.

We do use hatch vcs here and i import the version into the init.py file. i'm curious if there is some pypa discussion around using that file because it seems like on the scientific side of things, folks aren't sure what it is for.

so in short - i'd be a fan of either removing it from the template OR we also discussed having a simpler version of the template hatch new pyospackage --simple or --static (for static versioning) that drops dynamic versioning elements altogether.

for a beginner, who isn't yet using vcs dynamic versioning will be cognative overload that they don't need. I'd also argue even an intermediate user might struggle a bit with understanding dynamic versioning.

Here is our intro tutorial . Essentially when i/we teach this i'm going to tell people to:

1. remove dynamic versioning as a start and
2. to remove that about__.py file

It would be nice if hatch provided a simpler starting point that didn't assume vcs and that uses standard files. i'm creating a youtube video as well for this and in that video i suggested people remove it (i just recorded a prelim version today!).

[cdwilson]

but the current way matches what one would do for persisting version metadata when it comes from VCS like Git

Hi @ofek could you unpack this comment a bit more? I'm curious how the __about__.py "matches what one would do for persisting version metadata" the VCS workflow you mentioned (compared to sticking __version__ in __init__.py when using VCS like Git)

[ofek]

e.g. the version-file option of https://github.com/ofek/hatch-vcs#build-hook-options (which corresponds directly to the version_file option of https://setuptools-scm.readthedocs.io/en/latest/config/)

[cdwilson]

Thanks! Just wanted to make sure there wasn't a footgun if I stick __version__ in __init__.py instead.

[HLFH]

Personally, I prefer to use __init__.py, so I ditched __about__.py. And it works in a better way.

[lwasser]

we are leaning this way as well. it just means you'd have to actually delete the file after running hatch new. it's another step for a user (if they are new).