Start of Project Standards

Special Interest Groups SIG Documentation
1

I’ve started creating a page for Project standards and would love if some people contributed ideas about what all we think the standards should be. I think what is up there so far is realistic, but I think it could use some more meat.

9 Likes
2

For example, do we want to have stuff about commit messages on there?

3

Extreme nitpick, but you made a typo :smiley_cat:

A devnev when applicable

1 Like
4

Currently working my way towards bed. But feel free to fix it. If it’s there tmrw afternoon I’ll worry about it.

1 Like
5

fixed, thanks :heart: (filler text)

2 Likes
6

If I understand correctly, I believe the goal is to squash and merge PRs, right? I think it would be very helpful to define a format for merge commit messages like feat, fix, break, etc. Guidance around commit messages describing the goal of the code/change would also be helpful from an effective PR review perspective.

3 Likes
7

I think we can mostly pinch prior art from Nixpkgs for that. Their messages are pretty nicely formatted, IMO.

2 Likes
8

Thanks for pointing to that, I’m new to the whole ecosystem.
Seems like the labels there indicate where the commited code is going pkgs, lib and not what it does: bug fix, security fix, new feature. Has that worked fairly well so far?

Also, what’s the thought on using tooling like pre-commit instead of using reminders?

Instead of:

Check for unnecessary whitespace with git diff --check before committing.

Have this:

repos:
#could (should?) be a Auxolotl repo
repo: https://github.com/pre-commit/pre-commit-hooks 
    rev: v2.3.0
    hooks:
    -   id: end-of-file-fixer
    -   id: trailing-whitespace
9

My biggest gripe with pre-commit is that they are system dependant. I know to most that probably won’t matter since your all working from WSL, darwin or linux. But sometimes we don’t get a choice but to work on windows.

3 Likes
10

this is a bad idea in the context of package repos. it will give contributors much more difficulty in bisecting history

the commit messages/PR titles should describe what it does. for example, a pr named foo: 1.0.0 -> 1.0.1 doesn’t really need a label

i’d say so. nixpkgs’ labeling system is one of the more useful things i’ve found in a github repo, along with the good standard of commit messages. makes it very easy to see what has been reviewed with approvals labels, if it’s something you’re knowledgeable of with topic labels, and how taxing a nixpkgs-review run would be with ofborg’s rebuild-linux and rebuild-darwin tags

no go. we should require as little as possible on a contributors system, and in general i don’t see a need to depend on an external tool that will require additional setup

for cases like these it would be much easier to just use workflows to check PRs. this would require no setup for contributors (which as said before, is pretty important) and make issues easily available to them and other from anywhere

3 Likes
11

I’m also advocating for that “pkg: foo update” isn’t helpful. Agreed.

That’s great, it achieves the same thing of not making it a reminder but using tools to enforce process. I understand the reduction of dependency for contributors but it’s unfortunate that it’s not friction free (the workflow will find the issue but not fix it). It’s a lament, not a gripe.

That is unfortunate, didn’t realize it didn’t work in Windows.

12

To be honest I went with the windows example. But pre-commit hooks work differently on all systems. Its just that it is more noticeable on windows since some software’s don’t work on there.

13

I’ll take your word for it, I don’t have experience using it on a variety of platforms. It’s running through a Python runtime so it’s interesting that it’s so system dependent. I’ll keep that in mind if I need to use it on other systems and test/research thoroughly. Thanks for the heads up.

1 Like
14

Alright I’ll add commit messages for pushes & merges later today

4 Likes
15

I think I’ve added some sensible stuff for commit messages, feel free to message in here if anyone thinks there should be some changes

3 Likes
16

Maybe deciding the formatting tool used for new auxolotl contributions while it’s not too late would be nice.
I personally use and like more alejandra than nixfmt-rfc-style

2 Likes
17

This is a good idea, I’ve made a post to talk about which formatting tool to use.

1 Like
18

If we go for pre-commit, we could consider using git-hooks.nix

19

I believe all the python code present in nixpkgs should be formatted using black which is literally the open source standard formatter

3 Likes
20

yep. black follows pycodestyle to a T so I’m in agreement