Skip to content

Latest commit

 

History

History
80 lines (72 loc) · 2.93 KB

ABOUT.md

File metadata and controls

80 lines (72 loc) · 2.93 KB
Raw

About

genvi is a tool to start new Python projects.

It doesn't have versioning as it's expected to be used in a fire-and-forget fashion; generate the Python project and code on.

There isn't much anything special about genvi, it's just another Python project template among many others. Different strokes for different folks.

Alternatives

Other project templates you might want to check out:

FAQ

Why not using cookiecutter?
We don't need thousands of lines of code to mv a couple of files.
Why mangle the source repository itself to create a new project?
Mainly for DRY. Conceptually, if you were to create a project that generated a "perfect" project, shouldn't the generator project follow exactly the same rules and conventions? The downside is some extra clutter in the genvi repository.
Why does the template include building/distributing/server start/command line usage/etc.?
It is more robust to automatically set up everything and commit them to a version control before removing them. This way, if you ever need the features in the future, you can get them from the version control history.
Some pre-commit hooks disable the isolated environment with language: system, why?
Some tools like mypy won't work on their full potential if the rest of the dependencies are missing from the environment; and it makes little sense to reinstall the full the development setup.

You might want to integrate some tools (e.g. ruff, mypy) with your IDE, in which case the extra duplication becomes unnecessary.
Who uses make anymore? Why not using invoke, nox or tox for task management?
make is already available on most systems, and if not, it's easy to install. It is more coherent to get all the initial project requirements from a single interface where you are probably already getting Python and Git.

When working on multitude of project in different languages, it reduces the mental burden if you have a single way of managing projects. You don't want to require Python on your Go project just for the development tooling, for example. The answer to "How was testing done in this context?" is always make test
Having an 100% test coverage requirement gives false sense-of-security. Isn't that an overkill?
Yes.