Move built-in styles to a separate repo to start a shared/community library of styles

[andreoliwa]

Problem

As a developer, I want to be able to use my own styles so I'm not forced to adopt Nitpick's default styles. At the same time, I'd like to contribute some of my styles to a Nitpick library that can be reused by other developers.

The default styles currently live as resources within the Nipick package itself.

From https://github.com/andreoliwa/nitpick/issues/331#issuecomment-1081228940:

I'd like somehow to create a "shared Nitpick library" where people could contribute. Encourage people and projects to add their styles to be shipped as Nitpick built-ins. Either in individual .toml files or as a "preset".

Right now I'm the only one adding these built-in styles for my own use. I'd like to also cherry-pick and reuse styles from other people/projects.

Possible solution

• [ ] Create a separate nitpick-styles Python package
• [ ] Move the tests/test_builtin directory and all its automated tests of styles to the new repo
• [ ] Keep it as a Python package so it can be versioned, and people can install different versions
• [ ] keep the styles as resources
• [ ] Is there a better solution than this?

[andreoliwa]

Continuing here the discussion from https://github.com/andreoliwa/nitpick/issues/331#issuecomment-1081240232:

The whole reason I’ve been providing PRs is so we can handle the styles entirely independently ;-)

That's good feedback.

I was thinking of the built-in styles as a shared library of "building blocks" where people can:

• Reuse only the blocks they want;
• Contribute their own blocks.

Specifically, because your current Python style is rather far removed from current community best practices (line length 80 with bugbear extensions to 88, as encoded by black)

Oh, I also wasn't aware of that. I had the impression that 120 was more widely adopted these days.

I can solve this by creating 2 separate styles, something like:

• python\line-length-120.toml
• python\line-length-80-88.toml

and because I need to guarantee stability for our engineers, I created an internal repository that replaces all of the defaults.

Agreed, that's sensible. A versioned shared library would also guarantee this stability, provided that you would have all the styles you need in a specific version.

Apart from the exact contents of the default styles, you should definitely consider moving the default styles to a separate repository, just so you can decouple the nitpick release cycle from the default styles.

To have releases and automated tests of .toml files, I can think of a Python package with resources... the same way they work now but moved to a separate Python project.

I could also rely exclusively on Git tags. But then the styles would be gh://user/repo@version/style.toml and that means "HTTP requests".

On the other hand, the py:// styles are conveniently installed locally in the virtualenv.

I'm a bit on the fence.

I’d personally then recommend the styles are then updated to reflect community best practices and consensus a bit more closely, as that would help adoption better.

Yes, that would be great.

As I mentioned, I tried to provide a "library" so people wouldn't start their styles from scratch. But I also wanted to also reuse good styles created by others.

At the same time, giving developers the freedom to choose which styles to use or not (like with the line length mentioned above).

---

@mjpieters thanks for the valuable input so far. 🙏🏻 I'd like to hear more of your thoughts on this topic.

[mjpieters]

I do see the advantages of being able to version and package styles, and a Python package has the advantages of being a known entity that plays in the same ecosystem.

The downside is that a custom style needs to be installed separately. We currently have everyone install nitpick globally (e.g. with pipx or homebrew), but for a pre-commit hook we'd need to add the style package as a dependency. Which means that for a private package we also need to maintain a private PyPI server to host the versioned packages, and this applies to the Mega-Linter plugin too, which means we can't just re-use the new Mega-Linter plugin definition (you need a new RUN pip install ... line to add the deps).

That's a lot more overhead than the simpler nitpick init https://[company-name].github.io/coding-standards/nitpick-style bootstrap we have now.

And it is perfectly possible to structure your HTTPS target to have a version too; e.g. https://[company-name].github.io/coding-standards/v1/nitpick-style, it is just more work on the server side to set this up.

All in all it means that I like to keep both options for this.