Add changelog generation, releases, publish pypi package

[nongrata081]

🚀 The feature, motivation and pitch

• Would be nice to have automatically generated changelog from commit history. Maybe github's generated release notes or with git-cliff (example). Then it's easier to reason about what changes were introduced when.
• Would also be nice to see torchchat/releases populated as new updates are rolled out (e.g. like in torchtune/releases). Then it's easier to switch between different versions to test & reproduce functionality.
• Would also be nice to have a possibility to install torchchat via pip install as a pypi package. The currently existing torchcat pypi package doesn't represent the latest contents of this repo. Then it's easier to install torchchat with just one cli command, as with torchtune pip install torchtune

Alternatives

No response

Additional context

No response

RFC (Optional)

No response

[Jack-Khuu]

Thanks for the suggestions @nongrata081, you've hit on many of the things that I've been meaning to do (or bug others to add)

generated changelog

releases

Definitely something we plan to do when we start doing regular releases. Since we're still aggressively making changes we haven't been creating milestones, but it is in the plans.

pip install as a pypi package

This is something that we're interested in, but haven't gotten around to (you actually found our placeholder pypi listing)

[nongrata081]

@Jack-Khuu awesome! Would love to help. Please let me know if you think this is something I might have a look into?

[Jack-Khuu]

We would more than appreciate the help!!

If you want to give spinning up a pyproject a shot, please do!! (feel free to open up an issue if you run into any blockers or questions)

• I can also jot up a more detailed description when i get a sec

[nongrata081]

I've done some work on the commit to add changelog generation

Here are:

• Template for changelog gen
• generated changelog

I added 4 git tags in order to categorize all commits by months when they were created. I suggest to use semantic versions for this purpose further on (e.g. v0.1.0, v1.0.0, etc).

Here is also my suggestion to shape the Release Strategy. I can create few releases in my forked repo following it to showcase.

I didn't group commits by commit types as here, since in order to do that we'd have to have all commits formatted according to conventional commits format. We can introduce it with commitizen (a cli prompt for easy commiting according to the format). We can also configure both commit types in the cli-prompt and categories of commits in the CHANGELOG.md according to the preference.

As for packaging and dependency management I thought of poetry. Example: dspy pyproject.toml

@Jack-Khuu what you think?

[Jack-Khuu]

Thanks for the links! I'll try to take a look before the weekend

[Jack-Khuu]

Pardon the delay, I've been OOO (still am). Will take a look when I get back to office (Monday)

Thanks again for the contributions!!