Closed steveoh closed 1 year ago
Thinking about this a little more, I'm not sold on the changes from pylint and yapf to ruff and black. Right now it feels like "chasing the new shiny" by you guys who (to me) seem to live mostly in the javascript world that would impact myself and others in the office that I'm trying to teach/convince to use this template.
I'd like to see a little more explanation and discussion before introducing a change that will either require updating a lot of existing projects or require juggling two different sets of build tools for new and old projects.
Why are we changing all the
'
to"
? is that a default in black that needs to be updated?
Black is opinionated. You can read the FAQ for some answers to those types of questions.
Right now it feels like "chasing the new shiny"
I'm sorry it feels like we are chasing new and shiny but I have to disagree with you. This would be the first python tool chain change you have experienced since working for UGRC. Communities evolve and so do tools and the support they are receiving. We like to choose tools that are well supported and adopted by the community.
Black has been around for ~5 years and the python community has adopted it with open arms. YAPF just started receiving updates again but was mostly abandoned for the last few years. Ruff is newer. But its performance numbers and the fact that it replaces isort should be enough reason for all of us to rejoice in the change. The shift from configurable formatting to opinionated/uncompromising has happened in multiple programming languages/communities and will be the path going forward for some time. It's in our best interest to follow these trends.
... you guys who (to me) seem to live mostly in the javascript world that would impact myself and others in the office that I'm trying to teach/convince to use this template.
Scott and I do not live only in the javascript world. We write code in all the languages and not that it matters but probably more so than most of the others in the office combined. The impact of this change affects us all and should be mostly transparent. It should not affect the adoption of this template in anyway. New project will have different tools that on the surface perform the same job. I would be surprised if anyone in the office is aware of or cares what is formatting or linting their code. The vscode extension suggestions and settings.json will configure their environment to just work™ no matter what project they are working on. People can choose to migrate their projects if they want to use the improved tooling. There is no mandate or requirement to migrate tools. Build tooling does not change. Black also has documentation how how to not ruin your git blame with a style change.
I'd like to see a little more explanation and discussion before introducing a change that will either require updating a lot of existing projects or require juggling two different sets of build tools for new and old projects.
I brought it up a while ago in this issue trying to create a discussion but no one other than Scott showed interested. I'm happy to discuss this more now if everyone is ready.
I feel your pain, Jake. I'm not one that likes to chase after the new shiny stuff. It's hard for me to wrap my head around new tools and sometimes I push back. I think that's a good thing. I've also learned that Steve does not get offended by these types of questions and neither do I.
This change seems to be a good one to me. I'm very high on more opinionated, less configurable tools. Especially when it comes to code formatting and linting. I learned long ago that it's not worth arguing over things like '
vs. "
or where to add indents. I feel like JavaScript lost years of its life arguing over things like this years ago. Then prettier came along and everyone got back to actually building stuff. Life gets SO much easier when you just go with whatever the prevailing opinionated tool is and move forward.
I've tried black and it's really a painless switch especially if you take the time to apply the format commit the right way. Once I made the switch, I immediately noticed the performance improvement and then got back to not worrying about how my code was formatted.
I have less experience with ruff, but the fact that it seems to have huge momentum and replaces isort is enough of a reason for me to switch and see how it goes. I've never been able to get isort to work consistently between my machine and CI.
For others in the office using this template, I can't see how this would affect them much at all. The template makes it very easy to get a project going without having to worry about what tools it's using. Just bootstrap the project, install the dependencies, and get to work. Existing projects can be brought into alignment as you work on them. I don't feel like it's a huge push to upgrade everything right away.
See the first article in this newsletter for a much better (and more entertaining) overview than I gave of how prettier affected the JavaScript ecosystem.
This change updates some of our older tools