linter_config; or more broadly, options to enable automation
dHannasch opened this issue · comments
I want to add an option linter_config for changing the configuration of the linter, but if I just submit that you'll rightly stare at it in bewilderment, because couldn't someone easily just edit setup.cfg after running the cookiecutter?
Well, yes, yes they could. So, here's the situation. Sometimes people have an algorithm or what-have-you that they've experimented with in a Jupyter notebook or a script or something. They want to turn it into a proper Python package. I want them to turn it into a proper Python package. But they run into problems, get discouraged, and might abandon the whole thing. I can help them, but it's hard to figure out all the many things that might be wrong.
Fortunately, your cookiecutter is great for heading off common problems. Unfortunately, it's hard to sell people on the fact that they'll eventually run into packaging problems before they actually do. More precisely, it's hard to get people to actually take the trivial step of running the cookiecutter. Instead they'll just want to copy setup files from another project or such, 'cause hey, that has to work, right? And of course, once they've already started, it's much harder to disentangle their actual code from the packaging to start from scratch with your cookiecutter.
Fortunately, I can make your cookiecutter literally push-button. And I have.
(I haven't been beating this drum since I didn't get the impression you were super-interested in something that only worked on GitLab, and of course the GitLab files are separate files so it's not hard to maintain them regardless of whether they get into master. )
As you can see, I literally only present them with three of the options. I'd reduce it more if I could. Almost always, the important thing is to just get them going with something that immediately works.
...except...
...sometimes people, or teams, have their own linter config. And so, when they initially drop their code into src/whatever/, their tox tests immediately fail. So they shrug, abandon the cookiecutter, and start a different way. Copying from another repo does pick up the linter configuration, so initially everything "works", so they go down that path, and only later run into packaging problems.
If there's a way to change the initial linter config programmatically, then only one person in a group needs to set up their linter config in the group where they create their packages. The cookiecutter can automatically pull in the linter config (if provided) for every new package.
Now, I can do that "from the outside" by running the cookiecutter, then parsing setup.cfg and changing it. But that has a bad smell. I think the right way is to work with the cookiecutter.
But of course, linter_config is the kind of argument that it's hard to imagine anyone actually using when running the cookiecutter manually on the command line. Because if they're taking the step of running the cookiecutter manually, then either they'll edit setup.cfg themselves when they see their tox tests fail, or they'll abandon it without inspecting the error messages, and in either case they won't know to use linter_config when they run the cookiecutter (even if that one-person-in-the-group told them to, they won't remember). So linter_config is a feature that would probably only be used when running the cookiecutter And unfortunately, cookiecutter does not allow selectively suppressing command-line prompts, it's all-or-nothing: https://cookiecutter.readthedocs.io/en/2.1.1/advanced/suppressing_prompts.html
So it would be one additional option that almost everyone would skip past every time. I'm not sure if you'd be okay with that.
As an aside, it just now occurs to me that GitHub might be able to do the same things as GitLab. I'm experimenting a little with https://github.com/dHannasch/cookiecutter-pylibrary/tree/github-action-push-to-nameless and https://github.com/dHannasch/cookiecutter-pylibrary/tree/github-action-push-to-nameless-without-docker. Using a container image seems more reliable (and faster) than installing cookiecutter on-the-fly. So maybe we could automatically push to python-nameless with GitHub Actions, like Travis used to before everything broke. More importantly, it could mean a button people could press to write to their repo on GitHub. I'm guessing you might be way more excited about the "automatic cookiecutting" thing if we could do it on GitHub rather than GitLab.
(Alas, both https://github.com/stracquadaniolab/cookiecutter-github-action and https://github.com/tj-actions/cookiecutter-action are cookiecutters for GitHub Actions, not GitHub Actions for cookiecutters, so I'm figuring this out as I go along.)
(https://github.com/ionelmc/cookiecutter-pylibrary/blob/master/%7B%7Bcookiecutter.repo_name%7D%7D/ci/templates/.github/workflows/github-actions.yml does the whole matrix thing, which...might also be good for testing come to think of it, but at the moment I'm just trying to set it up to cut the cookiecutter at the push of a button. Anyway, this is all getting way off into the weeds, the point is just that if you're not willing to live with options like linter_config to enable automation on GitLab, but you would be to enable automation on GitHub, well, that's an option too.)
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?
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.)
Closing this cause travis is gone, and linter options have been removed. There's a single linter now: ruff.