linter_config; or more broadly, options to enable automation about cookiecutter-pylibrary HOT 3 CLOSED

Do I understand this correctly: you want to bring back the CI we had with travis in the past that built python-nameless? And that python-nameless repo is marked as a template so people can just one-click clone it into their accounts right?

I do want to get the CI running proper again, just haven't found the time :-)

Wouldn't converting https://github.com/ionelmc/cookiecutter-pylibrary/blob/master/.travis.yml to github actions be enough?

from cookiecutter-pylibrary.

I don't think marking python-nameless as a GitHub template allows any arguments? I've never used GitHub templates, but I can't find any mention of arguments in the documentation. GitHub templates just copy all of the files and folders straight, as far as I can tell, so the copied package would always be named python-nameless. I don't think anyone would want that, since changing the name of the package is actually really annoying if you don't already know all the places you need to change it. I (obviously) think there's a time and a place for a stripped-down interface that hides most of the parameters, but hiding all the parameters (which seems to be what GitHub templates do) would seem to make a cookiecutter basically useless.

What I'm talking about is actually kind of orthogonal to https://github.com/ionelmc/cookiecutter-pylibrary/blob/master/.travis.yml , though admittedly, success looks superficially similar in both cases. But the point here is to take the process of deploying to python-nameless and expose it to users so they can point it at their own repositories instead. So they would actually fork cookiecutter-pylibrary and click Run workflow on that. (Depending on exactly how GitHub Actions work, they might not even need to fork it, I haven't investigated.)

from cookiecutter-pylibrary.

Closing this cause travis is gone, and linter options have been removed. There's a single linter now: ruff.

from cookiecutter-pylibrary.