3 ms·

It was printing a warning about the deprecation for close to 5 years. I don't think a few more years of support would make much of a difference. > WARNING: Tes

It was printing a warning about the deprecation for close to 5 years. I don't think a few more years of support would make much of a difference. > WARNING: Testing via this command is deprecated and will be removed in a future version. Users looking for a generic test entry point independent of test runner are encouraged to use tox. https://github.com/pypa/setuptools/commit/cd84510713ada48bf33d4efa749c2952e3fc1a49 https://github.com/pypa/setuptools/commit/cd84510713ada48bf3...

baq 2y ago
Nobody reads these. It’s alert noise. If it broke every 10% of runs folks would notice. Brutal but there’s zero cost of ignoring the warning beforehand.
- kalaksi 2y ago
  I wouldn't say it's zero cost. It's a risk with potential to cost you. So there's some kind expected value to that cost and the risk grows the longer you ignore the warning
  - baq 2y ago
    I kind of agree - though I make a distinction between risk and cost in the same way you say 'potential cost' i.e. cost is realized risk. Until the risk materializes, you don't pay. The base scenario in this case is the classic thanksgiving turkey though - everything is fine until it isn't.
- SAI_Peregrinus 2y ago
  Often nobody even sees them. The software gets built by a CI system, there's no way for the CI system to alert on new warnings appearing, and nobody checks the logs. Maybe a staged process. Start with a warning as usual, to CYA. Nobody will care, but you can feel smug and say you told them. Then turn it into an error and add a flag that a user can set to turn that deprecation back into a warning. Setting the flag should be a trivial change, but since builds will fail it'll be noticeable. The build failure message should include the date the deprecated feature will be removed, a link to migration steps, and instructions on how to set the flag to allow builds to succeed. Then finally remove the feature. That would allow users a chance to schedule work to remove use of the deprecated feature.
denotational 2y ago
The warning only appears if you run `python setup.py test` (or equivalent), but the breakage occurs regardless of whether you were actually running this; if you depend on a package that doesn’t have a pre-built wheel, and the package attempts to import the removed module in its `setup.py`, then your build will break.
- dwattttt 2y ago
  Reason number 37 to hate "code as config"
  - pas 2y ago
    code as config is amazing. well can be, easily, it needs to be descriptive and composable. meaning it needs to be able to return data according to some schema. the point is, that the problem again is the lack of a clear boundary between the gathering, assembling, ordering, calculating and validating the steps required to prepare/build/install/load/use/and-so-on and the actual execution of those steps. Terraform, for example, has a plan and run phase. And in general the fear of too many layers (and in-situ DSLs) leads to very brittle and extremely inconvenient "interfaces" (ie. GitHub and Ansible programming in YAML comes to mind) ... Ideally build/packaging/setup steps themselves were written in a way that their reinterpretation[0] is easily possible. (So we don't need to litter the implementation with explicit hook points, etc.) [0] basically using interfaces and the visitor pattern, or in an FP way via the https://blog.rockthejvm.com/free-monad/ https://blog.rockthejvm.com/free-monad/
    - dwattttt 2y ago
      I think config _is_ the clear boundary between those gathering, ordering etc steps. The less expressive config is, the more regular and structured it is, and it becomes very easy to be descriptive and composable.
      - pas 2y ago
        from time to time config is just not willing to sit there in a list. it needs to be computed. just an example from a few days ago. someone needs to pull data from some remote service (maybe Vault), or generation of keys/entropy/etc. [0][1] of course this just means folks should wrap the whole thing in a program. but that's getting inefficient fast if every layer only accepts "env vars" or a plain JSON file. [0] https://github.com/nextauthjs/next-auth/pull/9638#issuecomment-2105161063 https://github.com/nextauthjs/next-auth/pull/9638#issuecomme... [1] https://github.com/nextauthjs/next-auth/pull/9638#issuecomment-2184292582 https://github.com/nextauthjs/next-auth/pull/9638#issuecomme...

baq 2y ago

Nobody reads these. It’s alert noise. If it broke every 10% of runs folks would notice. Brutal but there’s zero cost of ignoring the warning beforehand.

kalaksi 2y ago
I wouldn't say it's zero cost. It's a risk with potential to cost you. So there's some kind expected value to that cost and the risk grows the longer you ignore the warning
- baq 2y ago
  I kind of agree - though I make a distinction between risk and cost in the same way you say 'potential cost' i.e. cost is realized risk. Until the risk materializes, you don't pay. The base scenario in this case is the classic thanksgiving turkey though - everything is fine until it isn't.
SAI_Peregrinus 2y ago
Often nobody even sees them. The software gets built by a CI system, there's no way for the CI system to alert on new warnings appearing, and nobody checks the logs. Maybe a staged process. Start with a warning as usual, to CYA. Nobody will care, but you can feel smug and say you told them. Then turn it into an error and add a flag that a user can set to turn that deprecation back into a warning. Setting the flag should be a trivial change, but since builds will fail it'll be noticeable. The build failure message should include the date the deprecated feature will be removed, a link to migration steps, and instructions on how to set the flag to allow builds to succeed. Then finally remove the feature. That would allow users a chance to schedule work to remove use of the deprecated feature.

denotational 2y ago

The warning only appears if you run `python setup.py test` (or equivalent), but the breakage occurs regardless of whether you were actually running this; if you depend on a package that doesn’t have a pre-built wheel, and the package attempts to import the removed module in its `setup.py`, then your build will break.

dwattttt 2y ago
Reason number 37 to hate "code as config"
- pas 2y ago
  code as config is amazing. well can be, easily, it needs to be descriptive and composable. meaning it needs to be able to return data according to some schema. the point is, that the problem again is the lack of a clear boundary between the gathering, assembling, ordering, calculating and validating the steps required to prepare/build/install/load/use/and-so-on and the actual execution of those steps. Terraform, for example, has a plan and run phase. And in general the fear of too many layers (and in-situ DSLs) leads to very brittle and extremely inconvenient "interfaces" (ie. GitHub and Ansible programming in YAML comes to mind) ... Ideally build/packaging/setup steps themselves were written in a way that their reinterpretation[0] is easily possible. (So we don't need to litter the implementation with explicit hook points, etc.) [0] basically using interfaces and the visitor pattern, or in an FP way via the https://blog.rockthejvm.com/free-monad/ https://blog.rockthejvm.com/free-monad/
  - dwattttt 2y ago
    I think config _is_ the clear boundary between those gathering, ordering etc steps. The less expressive config is, the more regular and structured it is, and it becomes very easy to be descriptive and composable.
    - pas 2y ago
      from time to time config is just not willing to sit there in a list. it needs to be computed. just an example from a few days ago. someone needs to pull data from some remote service (maybe Vault), or generation of keys/entropy/etc. [0][1] of course this just means folks should wrap the whole thing in a program. but that's getting inefficient fast if every layer only accepts "env vars" or a plain JSON file. [0] https://github.com/nextauthjs/next-auth/pull/9638#issuecomment-2105161063 https://github.com/nextauthjs/next-auth/pull/9638#issuecomme... [1] https://github.com/nextauthjs/next-auth/pull/9638#issuecomment-2184292582 https://github.com/nextauthjs/next-auth/pull/9638#issuecomme...