various amendments #21
Conversation
There was a problem hiding this comment.
Thanks @dornech! I added a few comments.
Would you be interested in becoming a co-maintainer for The Hatchlor? 🌹
| # own developed alternative variant to hatch-vcs-footgun overcoming problem of ignored setuptools_scm settings | ||
| # from hatch-based pyproject.toml libraries | ||
| from hatch.cli import hatch | ||
| from click.testing import CliRunner |
There was a problem hiding this comment.
What is the advantage of this compared to the original version? It expects way more packages to be installed during execution time like click and hatch itself, which normally is not required to be present when you just want to install the package you have developed.
There was a problem hiding this comment.
This is required for retrieving the actual build version. It is an adjusted version of the footgun as commented.
I agree this might be overhead for non-developer installation but if hatch is installed anyway, there is no additional overhead.
There was a problem hiding this comment.
Not sure I really get it. My original code accomplished the same thing. It read out the version but only using modules that are shipped directly with Python. So the big advantage of my original code is that you don't need to have hatch installed to use the package. I know that developers of a package need to have hatch installed but you should always think about the users of what you are building. They should not be required to install hatch.
There was a problem hiding this comment.
If you do an "pip install -e" then you always see the last install version -- not the last commit version.
It is explained here:
https://github.com/maresb/hatch-vcs-footgun-example
But I agree: this is probably a small advantage compared to the setuptool_scm dependency. And it is only neceesary if one has very strict version dependencies in the code.
Probably refering to metadata or the local _version.py after a hatch build is a good compomise?
There was a problem hiding this comment.
Argh, I did miss that I eliminated the setuptools_scm dependency already because of using Hatch compared to the original footgun-version. the setuptools_scm did not work correctly with the version bumping.
Explained in more detail here - maresb/hatch-vcs-footgun-example#3: @maresb made also an suggestion how to call hatchling directly (without the click-overhead of Hatch as the front-end to hatchling).
| @@ -71,10 +77,104 @@ version-file = "src/{{ cookiecutter.pkg_name }}/_version.py" | |||
| packages = ["src/{{ cookiecutter.pkg_name }}"] | |||
|
|
|||
| [tool.hatch.build.targets.sdist] | |||
| artifacts = ["_version.py"] | |||
There was a problem hiding this comment.
Smart, so this is necessary for source distributions so that it is included?
There was a problem hiding this comment.
The _verison.py file is generated during build and is to be included for the installable installation I think.
There was a problem hiding this comment.
This worked out of the box for wheel files but not sure about sdists. Good point.
There was a problem hiding this comment.
To be honest I am not experienced with the difference between wheel and sdist-distributions.
| "Programming Language :: Python :: Implementation :: CPython", | ||
| ] | ||
| # direct dependencies of this package, installed when users `pip install {{ cookiecutter.project_slug }}` later. | ||
| dependencies = [ # ToDo: Modify according to your needs! | ||
| "typer", | ||
| "setuptools_scm", |
There was a problem hiding this comment.
setuptools_scm should not be needed for a normal, i.e. non-development, installation. It's not necessary to have it as a runtime requirement.
There was a problem hiding this comment.
I agree but it is the issue as above: it is the hatch-vcs-footgun in init.py ...
There was a problem hiding this comment.
Argh, I did miss that I eliminated the setuptools_scm dependency already because of using hatch compared to the original footgun-version. the setuptools_scm did not work correctly with the version bumping.
There was a problem hiding this comment.
BTW - the issue with setuptools_scm was discussed here
maresb/hatch-vcs-footgun-example#3
| hooks: | ||
| - id: mypy | ||
| args: ["--install-types", "--non-interactive"] | ||
| additional_dependencies: [types-tabulate, types-cachetools] | ||
|
|
||
| - repo: https://github.com/jorisroovers/gitlint |
There was a problem hiding this comment.
I really like the idea but would it be better to have this optional via cookiecutter? Gitlint is still having less than 1k Github stars and is it really used that often? I like it but it's not a commonly found best practice, is it?
There was a problem hiding this comment.
Well, to be honest: gitlint was the only commit-message linter I found. For automated generation of a changelog it is necessary to have proper commit messages. I struggled somewhat on that ...
Probably more professional developers than I am are much more familiar with this and do it while asleep but for me it was helpful.
I do not knoy how cookiecutter would be of any help here but probably I missed something there.
There was a problem hiding this comment.
Ah, I guess now I know what you mean with "optional via cookiecutter". You mean similar to the lock-file support i. e. controlling via y/n prompt during cookiecutter execution? I am afraid it is me lacking some cookiecutter / Python packaging experience that I did not get it directly. Sounds like a valid option.
Probably also an option fot the complete footgun-stuff ...
There was a problem hiding this comment.
Exactly, to make it gitlint an additional option. Bear in mind though that with every additional option, running unittests becomes more complicated since you need to test every possible path, not only the one that includes all features.
There was a problem hiding this comment.
Question: to do it perfect, I would have to delete the .gitlint config file after generation via the post_gen_project.py hook ?
There was a problem hiding this comment.
I tried to make the gitlint optional. Struggling with the post-generation hook to delete the .gitlint file, other error fixed.
| @@ -38,4 +45,4 @@ jobs: | |||
| hatch run lint:all | |||
| - name: Run Tests | |||
| run: | | |||
| hatch run test:pytest | |||
| hatch test | |||
There was a problem hiding this comment.
Nice, the new way of doing this! Thanks.
There was a problem hiding this comment.
My idea was to leave the testing for different versions and environments mainly with GitHub. This is achieved by setting the matrix for os / python version in the GitHub action and executing a hatch test in the standard hatch-test environment.
I was only struggling a little bit with the package dependencies, there might be some room for optimization.
|
General remark: I am afraid this pull request still has some escaping errors. Fix see subsequent commits from today. |
|
Regarding co-maintainer: I feel honoured you are asking. I am just not sure if I am experienced enough. I mean I think I am not a rookie in IT and in development but at least a newbie in the Python Packaging universe ... |
|
I would love to see PyScaffold become Hatch-enabled to allow to work with Hatch-based scaffolds and probably migrating Hatchlor to a PyScaffold template. So far I am struggling with Cruft which is less well maintained and does not work in my environment. |
|
PyScaffold follows a completely different approach and uses traditional tools like setuptools only. To make it hatch-based would mean to rewrite almost everything... Not sure that really makes sense and that this should be done. What would you gain from it? The idea was to have a lightweight Hatchlor for people using hatch (and there aren't that many) and PyScaffold for developers that want to stick with a traditional toolchain. |
|
Hm. My understanding was that PyScaffold helps to follow and adopt changes in an underlying template. I wonder why this should not be of interest for Hatch based delopment as for "traditional" toolchain. Only other tool I found is cruft but it is less well maintained and I am not yet too confident in this tool. |
Hi @FlorianWilhelm,
I spent some time on your Hatchlor.
I did some amendments you left over: I included two options for local comitting and versioning - bump-my-version/generate-changelog or semantic-release. Both are - if set up - easy to use. I included a basic config for both tools in the pyproject.toml template so everbody is free to use the one or the other.
Furthermore I added gitlint which I find useful to enforce conventional commit compliant commit messages - pretty useful if you automate the changelog generation with generate_changelog or semantic-release. gitlint is cool stuff and for example works also within PyCharm which is my favorite IDE (which is probably not surprising for the more professional Python developer than I would claim for myself).
Finally I did some rework on the GitHub workflows.
These are the main changes I think. Please find approriate comments in the README.md as well.