CI Bump black version

[merveenoyan]

This PR bumps black version. I only did this atm because I couldn't find out a way on how to modify a github actions workflow file from my own fork (it does make sense that I shouldn't do it 😅).
I did google it, it feels like a secret information only 10x devs know about and never tell anyone else.

[merveenoyan]

It's weird that I remember putting pip wheel metadata files to .gitignore yet it still creates and adds them automatically.

[BenjaminBossan]

I couldn't find out a way on how to modify a github actions workflow file from my own fork

Could you explain what you mean here, I don't get it :D

[merveenoyan]

@BenjaminBossan Sorry it's my assumptions again.

So the problem with black and other formatting libraries is that we use a specific pinned version in our pre-commit configurations, meanwhile on github workflow file, it installs whatever's latest (see below)
https://github.com/skops-dev/skops/actions/runs/2664820958/workflow#L32
Which causes tests to be sort of flaky. I wanted to open a PR to that file from my own fork but couldn't figure it out (and it makes sense that you shouldn't be able to modify it from your fork.) Am I allowed to edit it from a different branch in the original repository?

[adrinjalali]

This PR should also bump the version on the CI, which you can change here:

skops/.github/workflows/build-test.yml

Line 35 in ff5a4e1

pip install pytest black isort pytest-cov

It should also run the new black on the whole codebase and include the changes in a separate commit in this PR (this can also be a separate PR if we want to add it to git ignore revisions)

[BenjaminBossan]

I wanted to open a PR to that file from my own fork but couldn't figure it out (and it makes sense that you shouldn't be able to modify it from your fork.)

I'm not sure why it wouldn't work. But in the end, do you need your own fork? You can push to this repo directly.

[adrinjalali]

It would work from the fork, please DON'T push to this repo 🙈

[BenjaminBossan]

It would work from the fork, please DON'T push to this repo see_no_evil

For my better understanding, what is the problem with creating branches on this repo directly and base PRs on those branches?

[adrinjalali]

These are my reasons for advocating no branches on the main repo:

• Creating branches on the repo means there's a difference between people who have the rights to create those branches vs people who don't. And for the sake of creating a community, it's really important to have the same process for everybody contributing to a project so that we don't end up having "insider" vs "outsider" contributors.
• Forcing this on ourselves makes sure we have a CI which works with contributions from other forks, so that when somebody from the community tries to contribute, our CI doesn't break.
• It keeps the main repo's branches clean and meaningful. Feature branches don't have a place in the main repo if the platform allows forks and PRs from forks. The main repo's branches are only used for major long term features which require a branch in the main repo and several PRs into them, or the release branches.
• Branch names become irrelevant since we don't care about how a contributor (or us) names their branches on their own fork, they can do as they wish, and have as many as they wish.

[BenjaminBossan]

Got it, thanks for explaining. Maybe we should have a central place to write things like this or our discussion about squashing down?

[adrinjalali]

People at HF aren't on the same page when it comes to these topics, so I rather make it project specific. But I agree we should have this somewhere, in our contributing guidelines.

The work on this project started being much faster once I went on holiday then the conference this week, I haven't had a chance to add documentation or README for these issues :D :P

[merveenoyan]

I'm sorry for being a rookie, I thought forks weren't allowed to modify it. I couldn't see .github because I didn't fetch the upstream on my main, it was added later. I thought it was intentionally made like that. 😅

[merveenoyan]

I can simply modify github actions, no worries

[BenjaminBossan]

LGTM, thanks for making the update.

On a related note: It has always annoyed me how easy it is for the versions of the dev tools to get out of sync. There is a version for CI, a version for pre-commit hooks, a version for your dev environment. Ideally, there would be a single requirements file that specifies the versions for all those, but I don't know of any way to achieve that :/

[adrinjalali]

There might be a way to use _min_dependencies.py to get the version in both scripts, but we can figure that out later.

[adrinjalali]

we also need a comment here, and on the pre-commit config file that these two versions should be upgraded together so that we don't forget and they are kept in sync.