dev.py: alias build with install and add argument to only test specific modules with all

[damusss]

Reasoning:

• usually building stops at compiling. new contributors might not choose it thinking it won't install pygame - but it will. I have one "documented" case of this happening.
• when adding some features you usually don't need to test all modules. it would not be a problem if display tests didn't run fullscreen operations, that completely fuck up every other window state because it sucks for some reason. that annoying behavior might discourage the usage of all, and it should not be the case.

[Starbuck5]

I'm sort of -1.

The compilation guide says to use dev.py build - https://github.com/pygame-community/pygame-ce/wiki/Advanced-compilation-guide-%28for-developers%29#building-pygame . I'm curious about the situation where someone sees the command but doesn't read the description and decides not to use it.

Also it's fine not to use it, using pip install . is just slow, not wrong.

Regarding all, I've never used that command, but isn't the point to have a full checklist of things the PR needs ready to go? Not running certain tests seems antithetical.

---

But really this is Ankith's territory to review.

[damusss]

I'm curious about the situation where someone sees the command but doesn't read the description and decides not to use it.

I mean you are right about that documentation being pretty clear. I guess it should be linked to new developers instead of just telling them to use dev.py (I suppose that might have happened with the person I'm talking about). I still find the alias helpful tho

Regarding all, I've never used that command, but isn't the point to have a full checklist of things the PR needs ready to go? Not running certain tests seems antithetical.

What you say makes sense, but at the same time I don't really want to break the maximized status of ALL my open windows just because I want to make a commit. Maybe it's just me being "greedy", but it's annoying. Either a --skip-fullscreen option can exists (but sounds like too much work for a simple thing like this) or I think it's not bad to constrain the tests only. When you work on some things, there are only so much modules that could possibly fail. As the developer you can probably figure out if that's the case or not, and if you misscalculated the github checks are gonna stop you anyways. But as you said, this is more ankith territory, so let's wait.

[ankith26]

I'm basically +0 on this proposal. I don't see the strong need for these changes but at the same time adding this can do no harm. As long as the existing stuff keeps working I don't mind people extending dev.py with whatever extras they want.