clean up project root

[theorashid]

Still more to go here. Questions:

• Do we need to edit any of the workflows following these changes?
• Do we need the .gitpod.yml file? What is it doing?
• Can we move the readthedocs.yaml to docs/?
• What is the .gitattributes file doing? It won't work currently and do we still need it
• Do we need the buildosx file?
• Is the codecov.yml file used?
• Should conftest.py be moved to tests/? Is it used?
• Can CONTRIBUTING.md and CODE_OF_CONDUCT.md be moved anywhere like docs/ or .github?

cc: @jessegrabowski @maresb

[jessegrabowski]

Can we re-aliven this effort?

[theorashid]

I think most of my cuts still stand

[jessegrabowski]

Mostly im curious if @maresb or @ricardoV94 know the answers to the questions posed

[maresb]

Hey, I'm not particularly involved here, but your changes look great to me! Thanks a lot for the work, and I'm glad to see this effort revived. Here is my pass at these bullet points:

1. Do we need to edit any of the workflows following these changes?
   • At a glance I don't see anything. Anything particular I should check?
2. Do we need the .gitpod.yml file? What is it doing?
   • See https://www.pymc.io/projects/docs/en/latest/contributing/using_gitpod.html, it may need to be updated. If you think nobody is using it then we can delete it.
3. Can we move the readthedocs.yaml to docs/?
   • I get the impression that the repo root is more standard.
4. What is the .gitattributes file doing? It won't work currently and do we still need it
   • Oh, I know this! It's a remnant from when we were formerly using versioneer, so we should definitely delete it. (In case you're curious, it tells Git to substitute tags into the Format strings here. This is necessary to ensure that the .tar.gz and .zip artifacts associated with the GitHub release have the expected version numbers. These artifacts are actually important since they are occasionally used by downstream package maintainers.
5. Do we need the buildosx file?
   • Good question. It doesn't look like it is or was doing anything. Maybe @aloctavodia knows?
6. Is the codecov.yml file used?
   • It is running and would probably be very useful if it were plugged in to anything.
7. Should conftest.py be moved to tests/? Is it used?
   • It looks to me like it is being used. Indeed I'm used to seeing it under tests/ and I'd strongly expect it to be safe to move, but I'm not completely sure.
8. Can CONTRIBUTING.md and CODE_OF_CONDUCT.md be moved anywhere like docs/ or .github?
   • Good question. I personally think it's good to keep them in the root for discoverability.

[ricardoV94]

Agree with @maresb. Regarding gitpod some enthusiastic person who liked it added it, it's one of those things that different people will disagree and may flip-flop as some remove then readd. I would cautiously remove it, and if the interested people come back to want it reintroduce and make it a policy to keep it

[jessegrabowski]

We used to use versioneer and stopped? I really like it -- it's a hassle to have to do a PR to bump the version before releasing. What was the issue?

[maresb]

Not sure, but anyways, I prefer hatch-vcs which is a not-horribly-bloated equivalent of versioneer. But one thing at a time. This is PR is already a big step forward. We can do a follow-up with this.

[jessegrabowski]

I rebased this and made some additional deletions based on @maresb 's comments. There's a circular import error happening I guess because of the version stuff, not sure what's going on there yet -- would appreciate help trying to figure that out.

[theorashid]

I think setup.py should be redundant now with pyproject.toml

[jessegrabowski]

My understand was that you still need it, but it can just be a one-liner, literally just:

from setuptools import setup

if __name__ == "__main__":
    setup()

I think we might be able to delete MANIFEST.in though?

[maresb]

Probably best to rip off the bandage and go straight for hatch / hatch-vcs.

Here's a reasonably-recent example I did: https://github.com/dgilford/tcpyPI/blob/master/pyproject.toml

[maresb]

And ya, that means get rid of setup.py and MANIFEST.in.

The tricky thing is you need to test python -m build and verify that both the sdist and wheel contain the files you expect (both are somewhat independent). The files to include are driven by Git, and adjustable via tool.hatch.build.targets.sdist and tool.hatch.build.targets.wheel.

[jessegrabowski]

@maresb what's the right way to get a __version__ into __init__.py? Do I need to copy something like the footgun example in?

[maresb]

You only need the build package from PyPI. Then running python -m build in the repo root will create the sdist and wheel. Under the hood it will see that it needs to install hatchling and hatch-vcs, so you don't even need to install hatch. Yay standards!

[maresb]

from importlib.metadata import version

__version__ = version("pymc-extras")

[maresb]

I just gave this a thorough check, looking at both the sdist and wheel, and it looks solid to me. Thanks everyone!

[theorashid]

buildosx won't work not because setup.py is gone. Can we get rid of that too? Also we could use hatch scripts for the testing e.g. https://github.com/JaxGaussianProcesses/GPJax/blob/main/pyproject.toml#L93-L112