7 ms·

TLDR; "Dev: Oh, you must have been using undocumented behavior of ASDF. Your code will continue to work as before, but if you change this #\- to a #\/ it'll st

by ozten 5y ago

TLDR; "Dev: Oh, you must have been using undocumented behavior of ASDF. Your code will continue to work as before, but if you change this #\- to a #\/ it'll stop complaining. User: Our code used to work in ASDF-stable. Any warning at all breaks our build, so it's broken in ASDF-devel. Just make it work like it did in ASDF-stable again. ... User: That undocumented behavior works well for us, though. Dev: That behavior that is a burden for us as ASDF maintainers, and we want to clean up our code and stop supporting it altogether."

tgbugs 5y ago
Another TLDR would be; ASDF-stable is good enough that there isn't an incentive to update to a version of ASDF-devel that breaks backward compatibility.
- remexre 5y ago
  Well, I have to manually update SBCL's ASDF because otherwise package-local-nicknames aren't supported by uiop:define-package, and the new-uiop-loading needs to be done before my systems load for package-inferred-system to not choke...
- d3nj4l 5y ago
  So another Python 2 vs 3 situation?
  - kjs3 5y ago
    Seems somewhat less impactful than that, but analogous, yes.
  - tgbugs 5y ago
    Not quite. The analogy is present explicitly in the gist but the comparison isn't particularly useful for understanding the social dynamics of the situation here.
  - guenthert 5y ago
    Well, the Python community is a few orders of magnitude larger than the Common Lisp community, so more of a tempest in a teapot situation here.
  - im3w1l 5y ago
    This seems like a very minor thing in comparison. The python 2 to 3 thing had many big issues. It was impossible to automatically convert code from 2 to 3. It was very complicated to write code that would be compatible with both versions. If one of your dependencies was 2-only, then you had no choice but to wait for them. Meanwhile, with most software being on 2, libaries were incentivized to stay on 2. So there was a chicken and egg issue.
    - akkartik 5y ago
      Is there any impending prospect of major CL implementations distributing asdf-devel by default?
      - remexre 5y ago
        "asdf-devel" is just what this post is calling "releases newer than the ones implementations ship," which not only feels like an _incredibly_ slippery definition, but by definition, no, once an implementation starts shipping it it's no longer a -devel version. I know of at least one distro that forcibly upgrades the ASDF that SBCL ships, though.
        akkartik 5y ago
        :o
        p_l 5y ago
        And distro behaviour is part of why the only reason anyone recently bothered working on lisp packaging for debian is the requirement for source packages for software shipped in main repo, so for one program someone built enough tooling to replace old debian tooling and build pgloader the way it should be done.
- uncletaco 5y ago
  But isn't "breaking compatibility" here emitting a warning that the downstream is treating as an error (because they've chosen to treat warnings as errors)? I feel like emitting it as a warning doesn't break compatibility but the downstream complaining (sbcl?) happens to be high profile enough that they can raise a stink about it.
  - oalae5niMiel7qu 5y ago
    Quicklisp doesn't include projects that build with warnings, so CL programmers are strongly incentivized to treat warnings as errors.
    - etimmons 5y ago
      This is very misleading. See my other comment for more details: https://news.ycombinator.com/item?id=30052405 https://news.ycombinator.com/item?id=30052405
  - thayne 5y ago
    And specifically, a warning about using undocumented behavior.
- rbanffy 5y ago
  You test against a devel version so that your users don't have to find out your software is broken the moment the devel is promoted to stable. I run my tests against daily upstreams because I want to know something will break before my users find it out.
- throwaway81523 5y ago
  That TLDR worked for Python 2 for 10+ years after all.
p1necone 5y ago
Warnings breaking builds is something you should opt in to with the knowledge that warnings are not part of the fixed public API of the thing you're building against/using as a dependency. That's the whole point of warnings in the first place - they're a way to communicate that people might be doing something wrong, without hard failing their builds. Otherwise what would be the difference between a warning and an error? Likewise, opting in to warnings as failures in your build system is a perfectly reasonable decision if you want to be strict about quality, and catch potential issues early. But the fix for a warning you don't want to treat as a warning is to just suppress it somehow (or fix it anyway if it isn't a complete false positive), not demand the maintainer remove it. (Note I'm just replying to the context of your TLDR, not the whole situation, which I haven't read through yet.)
- oalae5niMiel7qu 5y ago
  The Quicklisp project repository (which is analogous to PyPI) requires that all projects included within it build without warnings. So treating warnings as errors isn't really opt-in in the CL community.
  - etimmons 5y ago
    This is very misleading. Exhibit A: the warnings in question have been present for 5 years and the projects that end up triggering the warnings have not been removed. I don't know when QL started building with an ASDF version that produced the warning, but the absolute latest would have been Feb, 2021. The full story is that there is a sub class of warnings called style warnings. Any warning that is not a style warning is typically called a "full" warning. Full warnings do break compilation by default (the spec even mandates this). Style warnings do not. That is why ASDF typically starts the deprecation process with style warnings. However, the bad system name warnings do not happen during compilation. It roughly happens during configuration time (as ASDF is building its plan). Since this is not compilation, neither the spec nor QL care about the specific types of warnings produced. That's why the bad system name warning is a "full" warning.
  - p1necone 5y ago

by ozten 5y ago

tgbugs 5y ago

Another TLDR would be; ASDF-stable is good enough that there isn't an incentive to update to a version of ASDF-devel that breaks backward compatibility.

remexre 5y ago
Well, I have to manually update SBCL's ASDF because otherwise package-local-nicknames aren't supported by uiop:define-package, and the new-uiop-loading needs to be done before my systems load for package-inferred-system to not choke...
d3nj4l 5y ago
So another Python 2 vs 3 situation?
- kjs3 5y ago
  Seems somewhat less impactful than that, but analogous, yes.
- tgbugs 5y ago
  Not quite. The analogy is present explicitly in the gist but the comparison isn't particularly useful for understanding the social dynamics of the situation here.
- guenthert 5y ago
  Well, the Python community is a few orders of magnitude larger than the Common Lisp community, so more of a tempest in a teapot situation here.
- im3w1l 5y ago
  This seems like a very minor thing in comparison. The python 2 to 3 thing had many big issues. It was impossible to automatically convert code from 2 to 3. It was very complicated to write code that would be compatible with both versions. If one of your dependencies was 2-only, then you had no choice but to wait for them. Meanwhile, with most software being on 2, libaries were incentivized to stay on 2. So there was a chicken and egg issue.
  - akkartik 5y ago
    Is there any impending prospect of major CL implementations distributing asdf-devel by default?
    - remexre 5y ago
      "asdf-devel" is just what this post is calling "releases newer than the ones implementations ship," which not only feels like an _incredibly_ slippery definition, but by definition, no, once an implementation starts shipping it it's no longer a -devel version. I know of at least one distro that forcibly upgrades the ASDF that SBCL ships, though.
      - akkartik 5y ago
        :o
        p_l 5y ago
        And distro behaviour is part of why the only reason anyone recently bothered working on lisp packaging for debian is the requirement for source packages for software shipped in main repo, so for one program someone built enough tooling to replace old debian tooling and build pgloader the way it should be done.
uncletaco 5y ago
But isn't "breaking compatibility" here emitting a warning that the downstream is treating as an error (because they've chosen to treat warnings as errors)? I feel like emitting it as a warning doesn't break compatibility but the downstream complaining (sbcl?) happens to be high profile enough that they can raise a stink about it.
- oalae5niMiel7qu 5y ago
  Quicklisp doesn't include projects that build with warnings, so CL programmers are strongly incentivized to treat warnings as errors.
  - etimmons 5y ago
    This is very misleading. See my other comment for more details: https://news.ycombinator.com/item?id=30052405 https://news.ycombinator.com/item?id=30052405
- thayne 5y ago
  And specifically, a warning about using undocumented behavior.
rbanffy 5y ago
You test against a devel version so that your users don't have to find out your software is broken the moment the devel is promoted to stable. I run my tests against daily upstreams because I want to know something will break before my users find it out.
throwaway81523 5y ago
That TLDR worked for Python 2 for 10+ years after all.

p1necone 5y ago

Warnings breaking builds is something you should opt in to with the knowledge that warnings are not part of the fixed public API of the thing you're building against/using as a dependency. That's the whole point of warnings in the first place - they're a way to communicate that people might be doing something wrong, without hard failing their builds. Otherwise what would be the difference between a warning and an error? Likewise, opting in to warnings as failures in your build system is a perfectly reasonable decision if you want to be strict about quality, and catch potential issues early. But the fix for a warning you don't want to treat as a warning is to just suppress it somehow (or fix it anyway if it isn't a complete false positive), not demand the maintainer remove it. (Note I'm just replying to the context of your TLDR, not the whole situation, which I haven't read through yet.)

oalae5niMiel7qu 5y ago
The Quicklisp project repository (which is analogous to PyPI) requires that all projects included within it build without warnings. So treating warnings as errors isn't really opt-in in the CL community.
- etimmons 5y ago
  This is very misleading. Exhibit A: the warnings in question have been present for 5 years and the projects that end up triggering the warnings have not been removed. I don't know when QL started building with an ASDF version that produced the warning, but the absolute latest would have been Feb, 2021. The full story is that there is a sub class of warnings called style warnings. Any warning that is not a style warning is typically called a "full" warning. Full warnings do break compilation by default (the spec even mandates this). Style warnings do not. That is why ASDF typically starts the deprecation process with style warnings. However, the bad system name warnings do not happen during compilation. It roughly happens during configuration time (as ASDF is building its plan). Since this is not compilation, neither the spec nor QL care about the specific types of warnings produced. That's why the bad system name warning is a "full" warning.
- p1necone 5y ago