5 ms·

> Black formats things differently depending on the version. Then add black as part of your environment with an specific version...

by kuu 4y ago

bombolo 4y ago
Or wait until a more sensible formatting tool comes along. Reformatting the whole code every version isn't so good. It's also very slow.
- fnord123 4y ago
  Install pre-commit: https://pre-commit.com/ https://pre-commit.com/ Set black up in the pre-commit with a specific version. When you make a commit it will black the files being committed using the specific version of black. As it's a subset, it's fast. As it's a specific version, it's not going back and forth. I hope this solves your issues.
  - bombolo 4y ago
    It doesn't… people use a million different distributions. Forcing everyone to use a single version of black means that people will just not bother with your project. The authors of black just don't understand that it'd be ok to introduce new rules to format new syntax, but it isn't ok to just change how previous things work.
    - jsmeaton 4y ago
      This is mostly nonsense and FUD. We have virtualenvironments, requirements files, setup.py with extra_requires that can all be used to manage versions without relying on the particular packages installed on an OS. Most people contributing to open source would be familiar with at least some of these methods and if they are not it’s a good opportunity for learning. And if they are not, then maintainers can pull, run black over the diff, and commit. CI prevents poorly formatted code from entering main. The actual changes between black versions of late have been minor at best. You’re making a mountain out of a molehill. Having a tool that dictates formatting is a lot less oppressive to new developers than 100 comments nitpicking style choices.
      - bombolo 4y ago
        > Having a tool that dictates formatting is a lot less oppressive to new developers than 100 comments nitpicking style choices. Yes, it would work very well if said tool didn't change its mind every 6 months, generating huge commits at every bump > Most people contributing to open source would be familiar with at least some of these methods and if they are not it’s a good opportunity for learning. You seem unfamiliar with the fact that other people aren't necessarily clones of yourself and might not behave like you. > CI prevents poorly formatted code from entering main. If you run black on CI… which of course I don't since every time they make a new version I'd have the CI start failing. And no pinning is not a "solution"… it's at best a workaround for badly written software. > The actual changes between black versions of late have been minor at best. You’re making a mountain out of a molehill. If you have 10 lines of code, I guess your diff can't be more than 10 lines. If you have more than 10 lines…
        jsmeaton 4y ago
        I’m working in a Python code base with multiple millions of files and not for the first time. It’s not the problem you make it out to be. The changes between black versions have been almost unnoticeable for years.
    - mvanbaak 4y ago
      since developing in python should be done in a virtual env to start with, I fail to see how this will be any problem. The pre-commit documented version of black will be installed in the venv of the project, problem solved.
    - fnord123 4y ago
      I think you haven't understood what I've told you. Please look into pre-commit and using it.
      - bombolo 4y ago
        I understood but I disagree.
wodenokoto 4y ago
That would only make it more likely that two developers would be using two different versions of Black. The further you get away from the project folder the more likely each developer is to have a different environment.
- adammarples 4y ago
  Just put a versioned black into pre-commit yaml and put that in your source and forget about it
  - bombolo 4y ago
    So now we have one more (useless) build requirement for developers?
    - adammarples 4y ago
      pre-commit is very useful, in my opinion. When organising code from a lot of Python developers at least, getting the boring stuff like formatting, import ordering, linting, mypy etc. sorted is a time saver.
      - bombolo 4y ago
        Do you know how slow all of that is? Do you want to run all of that per every commit? The result would be people making a monocommit rather than incremental commits that is easy to review one by one.
        beaugunderson 4y ago
        I do like pre-commit for enforcing linted and typed code but the speed (or lack thereof) does hurt.
        adammarples 4y ago
        Yes, so fast that it makes no difference at all to me. How slow do you think black is?
bombolo 4y ago
I'm sure you will get many contributions to your project if you refuse people with the wrong distribution from contributing.
- biorach 4y ago
  I think by now it's a reasonable requirement for contributors to use a virtualenv when working on a project

> Black formats things differently depending on the version. Then add black as part of your environment with an specific version...

by kuu 4y ago

> Black formats things differently depending on the version. Then add black as part of your environment with an specific version...

bombolo 4y ago

Or wait until a more sensible formatting tool comes along. Reformatting the whole code every version isn't so good. It's also very slow.

fnord123 4y ago
Install pre-commit: https://pre-commit.com/ https://pre-commit.com/ Set black up in the pre-commit with a specific version. When you make a commit it will black the files being committed using the specific version of black. As it's a subset, it's fast. As it's a specific version, it's not going back and forth. I hope this solves your issues.
- bombolo 4y ago
  It doesn't… people use a million different distributions. Forcing everyone to use a single version of black means that people will just not bother with your project. The authors of black just don't understand that it'd be ok to introduce new rules to format new syntax, but it isn't ok to just change how previous things work.
  - jsmeaton 4y ago
    This is mostly nonsense and FUD. We have virtualenvironments, requirements files, setup.py with extra_requires that can all be used to manage versions without relying on the particular packages installed on an OS. Most people contributing to open source would be familiar with at least some of these methods and if they are not it’s a good opportunity for learning. And if they are not, then maintainers can pull, run black over the diff, and commit. CI prevents poorly formatted code from entering main. The actual changes between black versions of late have been minor at best. You’re making a mountain out of a molehill. Having a tool that dictates formatting is a lot less oppressive to new developers than 100 comments nitpicking style choices.
    - bombolo 4y ago
      > Having a tool that dictates formatting is a lot less oppressive to new developers than 100 comments nitpicking style choices. Yes, it would work very well if said tool didn't change its mind every 6 months, generating huge commits at every bump > Most people contributing to open source would be familiar with at least some of these methods and if they are not it’s a good opportunity for learning. You seem unfamiliar with the fact that other people aren't necessarily clones of yourself and might not behave like you. > CI prevents poorly formatted code from entering main. If you run black on CI… which of course I don't since every time they make a new version I'd have the CI start failing. And no pinning is not a "solution"… it's at best a workaround for badly written software. > The actual changes between black versions of late have been minor at best. You’re making a mountain out of a molehill. If you have 10 lines of code, I guess your diff can't be more than 10 lines. If you have more than 10 lines…
      - jsmeaton 4y ago
        I’m working in a Python code base with multiple millions of files and not for the first time. It’s not the problem you make it out to be. The changes between black versions have been almost unnoticeable for years.
  - mvanbaak 4y ago
    since developing in python should be done in a virtual env to start with, I fail to see how this will be any problem. The pre-commit documented version of black will be installed in the venv of the project, problem solved.
  - fnord123 4y ago
    I think you haven't understood what I've told you. Please look into pre-commit and using it.
    - bombolo 4y ago
      I understood but I disagree.

wodenokoto 4y ago

That would only make it more likely that two developers would be using two different versions of Black. The further you get away from the project folder the more likely each developer is to have a different environment.

adammarples 4y ago
Just put a versioned black into pre-commit yaml and put that in your source and forget about it
- bombolo 4y ago
  So now we have one more (useless) build requirement for developers?
  - adammarples 4y ago
    pre-commit is very useful, in my opinion. When organising code from a lot of Python developers at least, getting the boring stuff like formatting, import ordering, linting, mypy etc. sorted is a time saver.
    - bombolo 4y ago
      Do you know how slow all of that is? Do you want to run all of that per every commit? The result would be people making a monocommit rather than incremental commits that is easy to review one by one.
      - beaugunderson 4y ago
        I do like pre-commit for enforcing linted and typed code but the speed (or lack thereof) does hurt.
      - adammarples 4y ago
        Yes, so fast that it makes no difference at all to me. How slow do you think black is?

bombolo 4y ago

I'm sure you will get many contributions to your project if you refuse people with the wrong distribution from contributing.

biorach 4y ago
I think by now it's a reasonable requirement for contributors to use a virtualenv when working on a project