Hi folks,
In January, Github is making it easier to change the default branch name
with a toggle on the website:
https://github.com/github/renaming
I know lots of other projects have done this (including maestro) and we
could do it ourselves, but I'd like to propose that we do this as soon as
GH has the tooling in place to handle it for us.
If anyone objects we can dig into this during a team meeting or something,
but personally this kind of seems uncontroversial and should be easy to
implement.
-Matt
Dear yt-dev
I recently found out about https://pre-commit.ci, and I'd like to propose we adopt this tool as
part of our CI for linting/auto-fixing.
The idea is that this automatically runs
$ pre-commit run --all-files
on each pull request and commits to the corresponding branch to auto-fix errors with
pre-commit hooks (black, isort and flynt in our case).
I'm reaching out to you because this would have small repercusions on everyone's
workflow. Let me try to give a comprehensive description of gains and costs in the following.
what it gets us
a simplification of our CI tooling, namely:
- `tests/lint_requirements.txt`
- `.github/workflows/style-checks.yaml`
- https://github.com/yt-project/slash-command-processor
all become useless
`.github/PULL_REQUEST_TEMPLATE.yaml` will also be simplified as all linting items in `PR
Checklist` become redundant.
On top of this, new hooks could be seamlessly added in the future without increasing the
entry barrier for occasional contributors (as installing pre-commit hooks locally is and
remains an opt-in).
what it costs us
- "zero" configuration: the only requirement is `.pre-commit.yaml`, which is already part
of the repo.
- minor updates to .pre-commit-config.yaml, namely :
- bumping black's version
(reason: black's `--exclude` flag is overidden by pre-commit's `--all-files`, but more
recent versions of black have a `--force-exclude` flag that overcomes this)
this will require a new PR to adopt black's latest (minor) updates in code styling
- signing up tohttps://pre-commit.ci (free)
what this changes to your workflow
PRs will be automatically fixed by the bot, so you'll either need to occasionally run `git pull` or `git push
--force` to account for it.
Note that this can be avoided completely by installing pre-commit hooks locally which is
and will remain an opt-in, see
https://yt-project.org/docs/dev/developing/developing.html#pre-commit-hooks.
Let me know what you think. Take care, and happy new year !
Cheers, Clément
Hi yt-dev,
I have been working on an update to our blog, which is currently on the
yt-project.org website here:
https://blog.yt-project.org/
as you can see, there haven't been updates to it in quite some time. Matt
and I have ported all of the old posts from this blog to a hugo page that
has tagging and categorization, so one can filter blog posts based on
search interest. Here's what it looks like right now:
munkm.github.io/yt-blog/
and here is the repo currently:
https://github.com/munkm/yt-blog
What do you all think? I think we could get some very cool contributions to
the blog this way.
-Madicken
PS: I presented this blog at the yt user's workshop a few weeks ago! If you
want to see it in action you can watch it here:
https://www.youtube.com/watch?v=wKh_8AAlFhY
Hi folks,
For a while, we've had two projects "incubating" in the org data-exp-lab,
which is tied to the research group I'm in here at UIUC. These are the
"widgyts" repo, which has some jupyter widgets in it, and "yt_idv" which is
where the IDV now lives.
I'd like to propose moving these to yt-project. I don't see this as being
very controversial, but I thought I'd give the opportunity for folks to
chime in yay/nay.
Thanks,
Matt
