Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure manifest tracks package version via module's __version__ attribute #27

Closed
wants to merge 1 commit into from

Conversation

bruno-f-cruz
Copy link
Member

This PR splits an independent commit from #26 to allow the project.toml manifest file to track the version of the package from a private __version__ attribute.

Users can also now get the version by calling:

import harp
version = harp.__version__

@bruno-f-cruz bruno-f-cruz added the feature New planned feature label May 20, 2024
@bruno-f-cruz bruno-f-cruz requested a review from glopesdev May 20, 2024 17:02
@@ -1,3 +1,5 @@
from harp.io import REFERENCE_EPOCH, MessageType, read
from harp.reader import create_reader
from harp.schema import read_schema

__version__ = "0.2.0"
Copy link
Contributor

@glopesdev glopesdev May 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I realise I do have one issue with this.

The way versioning is done currently is by using git tags instead of hard-coded strings, and I'm realising I actually really like that because you don't have to worry about updating any strings until you do the release and then uploading to pip just works consistently. Same with local builds in case there are local changes setup tools assumes a patch and pre-release suffix automatically as long as you don't hard-code things.

So I guess I would rather do this the other way around and backfill the string automatically from the git release tag, rather than having the release version be set from a string we have to manually remember to update.

Is that possible?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would assume it needs to be done at the same time as the tag is added? Maybe we close this PR for now. At the time I wanted to use this to automatically generate a Deprecated user message but I ended up dropping it anyway.

@glopesdev glopesdev closed this May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New planned feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants