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

dynamic versioning, reformat pyproject.toml, switch pytest.ini to pyproject.toml #519

Closed
wants to merge 5 commits into from

Conversation

bagel897
Copy link
Contributor

@bagel897 bagel897 commented Nov 4, 2022

Pulls versioning from PR + git - necessary for automatic DB upgrades
We need the tags to work first. Also reformatted the pyproject.toml. Please try versioning it yourself first and let me know if you want me to update CI to match.
replaces #450
closes #414

@bagel897 bagel897 changed the title dynamic versioning dynamic versioning, reformat pyprojec.toml, switch pytest.ini to pyproject.toml Nov 4, 2022
@bagel897
Copy link
Contributor Author

bagel897 commented Nov 4, 2022

How should I leave credit for #450 - I copied it verbatim?

@bagel897 bagel897 mentioned this pull request Nov 4, 2022
4 tasks
@bagel897 bagel897 changed the title dynamic versioning, reformat pyprojec.toml, switch pytest.ini to pyproject.toml dynamic versioning, reformat pyproject.toml, switch pytest.ini to pyproject.toml Nov 4, 2022
@lieryan
Copy link
Member

lieryan commented Nov 5, 2022

To retain attribution, you can recreate the git commit by setting @gliptak as author. Easiest way to do this, if you're copying the commit more or less verbatim would be using git cherry-pick.

Otherwise, there are some environment variables you can set when creating the commit in command line to override the author fields: https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables, set them to the value that was on the original commit.

I'm not quite sure how dynamic versioning works, I'll need to play with that a bit too see how I like them, though I would have preferred to keep as much of pyproject.toml as possible to be statically defined, to keep things simple for packaging tools. If it needs a dynamic component for the purpose of database re-generation, it should be the version number set in rope/init.py that have additional logic to append dirty/unreleased changes information to the version number, e.g. adding a hash there.

@bagel897
Copy link
Contributor Author

bagel897 commented Nov 5, 2022

Ok so how dynamic versioning works is:

  1. If there's a git tag on the current commit, it uses that version - say v1.4.0 would map to 1.4.0
  2. Otherwise, you take the previous git tag and do something with the commit number to get a unique dev tag like 1.4.0-dev12856.r204

The first part means it'd be possible to create a tag and have automatic releases rather than have to bump the version manually.
The second part helps for developing stuff like auto import without having to manually wipe the DB every commit. (but this isn't nessecary)
If we don't want to use dynamic versioning, then we should remove setuptools-scm from the build dependencies. It's really up to you since you maintain rope.

As for the attribution, I'll cherry pick it later, thanks.
Edit: a disadvantage would be we'd have a runtime dep on setuptools-scm to get the version

@lieryan
Copy link
Member

lieryan commented Nov 21, 2022

Closing this as this is now replaced with #526.

@lieryan lieryan closed this Nov 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Migrate pytest.ini to pyproject.toml
2 participants