store project metadata in pyproject.toml

[aradkdj]

I think we could also remove the functionally empty setup.py (could be added if that's ok).

[zzzeek]

OK but let's use hatch

the commit you see for example at sqlalchemyorg/zzzeeksphinx@84607bb I did like this:

hatch new --init

boom, there's your pyproject.toml file. I was going to use hatch for all the sqlalchemyorg stuff

[aradkdj]

Sure thing, just to confirm, https://github.com/sqlalchemyorg/zzzeeksphinx/ seems to have been storing the version in its __init__.py since its inception. Should I migrate to that scheme and delete .github/workflows/release.yml?

Edit: I meant .github/workflows/scripts/update_version.py, but .github/workflows/release.yml interacts with it quite a bit.

[zzzeek]

Sure thing, just to confirm, https://github.com/sqlalchemyorg/zzzeeksphinx/ seems to have been storing the version in its init.py since its inception. Should I migrate to that scheme

yes

and delete .github/workflows/release.yml?

this has buzzed past my knowledge of these tools. This looks like the release action that @CaselIT wrote for this. What happens to it?

[CaselIT]

the idea there was that the release pipeline would:

• optionally set the version you tell it to and commit that change
• build the wheel and sdist
• update the version and commit the update
• push to pypi the create wheel and sdist

I don't see much issues in keeping the same flow also if we were to update to pyproject

[CaselIT]

OK but let's use hatch

the commit you see for example at sqlalchemyorg/zzzeeksphinx@84607bb I did like this:

hatch new --init

boom, there's your pyproject.toml file. I was going to use hatch for all the sqlalchemyorg stuff

I think it would make sense to do this in another PR

[aradkdj]

the idea there was that the release pipeline would:

• optionally set the version you tell it to and commit that change
• build the wheel and sdist
• update the version and commit the update
• push to pypi the create wheel and sdist
  I don't see much issues in keeping the same flow also if we were to update to pyproject

If my understanding of .github/workflows/scripts/update_version.py and the release pipeline are correct, as of right now that's what happens. FWIW did manually test update_version.py to try and up my confidence in it still working as expected. However, with the move to hatch, update_version.py might no longer be necessary by using and parsing output from hatch itself (https://hatch.pypa.io/latest/version/#updating)

[CaselIT]

it's not clear what that command does. It goes and edit the python file so that it has the new version?
That can't be right. Maybe it only works if the version is in the pyproject file?

from my point of view it's fine to keep it in the pyproject file only

[CaselIT]

@zzzeek you prefer having hatch added to this pr?

personally since this seem to work i would leave as is so we can merge and release 0.7

[zzzeek]

So release.yml relies on setuptools ? Otherwise why does it matter ?

[CaselIT]

Not really. Meaning it relied on how things worked before. Now it resiel on how things work with this pr, if we add hatch it will have to rely on how hatch works.

Overall it's likely the same either with any way we want to go with this

[zzzeek]

release.yml seems to be reliant on the hardcoded version in setup.cfg but otherwise doesnt care about setuptools.

can we do a separate PR that updates release.yml and setup.cfg to use a normal version in __init__.py first?

[CaselIT]

doesn't really make much sense since this pr already changes both of them.

so if anything I would do such a change after this pr or in this pr. also need to look at how hatch version upgrade works, since if it's only for the pyproject defined case I thing it would make sense to keep the version only in pyproject

[aradkdj]

Hatch can parse and upgrade versions from an arbitrary file using an arbitrary regex. Configured via the tool.hatch.version.path and tool.hatch.version.pattern respectively [1] and keeping it in sync between zimports.__version__ and the package metadata

[1]https://hatch.pypa.io/1.6/version/#configuration

[CaselIT]

@zzzeek it's fine either way for me, I just want to release a new version of zimports.
Otherwise I release with the current machinery then we ca do whatever for the next one.

[zzzeek]

OK so ultimately I want:

• pyproject with hatch
• version number is in __init__.py
• we still have some kind of github action that does releases

how can we get there?

[CaselIT]

Well we can either do that change here or in a follow up.
Maybe in a follow up is better?

[aradkdj]

I'm open to making the hatch switch in this PR or another

The only things I'm not clear about are how to keep the functionality release.yml already has and how to test my approach(es) without making a release by accident. Maybe @CaselIT you have some useful pointers in that regard

[zzzeek]

OK @CaselIT can we merge this as-is with the setuptools version which assumes we do not need to change release.yml in any way, is that correct?

[CaselIT]

release.yml should work with the changes in this pr.

The only things I'm not clear about are how to keep the functionality release.yml already has and how to test my approach(es) without making a release by accident. Maybe @CaselIT you have some useful pointers in that regard

it should be easy do to, we replace the current script with hatch version ..., defaulting the input argument to patch. everything else in release should work without other changes

[CaselIT]

created #48 for hatch