5 ms·

People here should also review the follow-up post: https://mailman.common-lisp.net/pipermail/asdf-devel/2022-January/006681.html https://mailman.common-lisp.net

People here should also review the follow-up post: https://mailman.common-lisp.net/pipermail/asdf-devel/2022-January/006681.html https://mailman.common-lisp.net/pipermail/asdf-devel/2022-Ja... This part is especially relevant to some of the discussion in this thread: > I understand that confronting this issue is more difficult than talking about whether or not ASDF should be issuing a warning. But that's not the question that is at hand.

reikonomusha 5y ago
There are project X and project Y. X is a critical, core library. Y is a very popular project. X and Y are both open source projects with permissive licenses. Y depends on X. As a convenience to X itself, X makes a change that causes warnings in dependent projects (basically every project in existence). To fix the warnings, dependent projects must rename their sub-project identifiers. For Y, this means the `Y-module` identifier must change to `Y/module`. (Alternatively, you can keep `Y-module`, but you have to split apart and slightly restructure your build system files.) Y does not want to do that because Y's project has been working fine for a decade. The change does not benefit Y. As a user of X, Y would prefer to keep the systems named as is. X does it for them anyway and makes a PR. Y rejects the PR. Y does not want this change. Y even believes that X should be motivated to stay backwards compatible because a popular project like Y doesn't want to change. X writes a post smearing Y. X also lambasts the Common Lisp community at large for not jumping in to support X's call for changing Y. I absolutely fail to see how the Common Lisp community is complicit in anything wrong... or anything at all, for that matter. I don't feel like I'm a poor community citizen because I don't get in the middle of my neighbor's disputes with the water company we both use.
- brabel 5y ago
  It's very common that people take the behaviour of one or two people they actually interact with as the behaviour of the "community". Jumping to conclusions is a favourite past-time. In this case, Y actually affects a lot of members of the community, but I guess most couldn't be bothered to express their opinions. I don't know if the proposed change has strong enough motivation to break backwards compatibility in a language that values backwards compatibility extremely highly (or am I jumping to conclusions too?). But feels like, on the surface, the change is cosmetic and hence uncalled for?
  - reikonomusha 5y ago
    A long time ago, countless projects started using X in a way that wasn't documented (specifically, using X to define multiple modules in one file, instead of one module per file), and it has worked forever just fine. I consider it an unintended (and nice) feature. X no longer wants to support this use-case, because they discovered that by not supporting it, they can clean up X's code a bit, and it makes X more efficient at certain tasks. So X turned this into a warning, and is waiting for downstream projects to fix their (new) warnings, before axing this feature. But one popular project, Y, refused to make the change which clears the warning (possibly hoping that X will be more careful to support, not break, idiomatic uses of X). In the end, project Y voluntarily and without friction added a maintainer who would be willing to keep up with these changes (which were considered by Y to be frivolous). Eventually the system was renamed.
    - p_l 5y ago
      I'd like to add that the fact that you're supposed to use only one DEFSYSTEM form per ASD file wasn't very advertised, at least back when I wrote my first ASDF systems (back when ASDF2 was still in the future) and since then one rarely delved again into full rereading of the manual.

reikonomusha 5y ago

There are project X and project Y. X is a critical, core library. Y is a very popular project. X and Y are both open source projects with permissive licenses. Y depends on X. As a convenience to X itself, X makes a change that causes warnings in dependent projects (basically every project in existence). To fix the warnings, dependent projects must rename their sub-project identifiers. For Y, this means the `Y-module` identifier must change to `Y/module`. (Alternatively, you can keep `Y-module`, but you have to split apart and slightly restructure your build system files.) Y does not want to do that because Y's project has been working fine for a decade. The change does not benefit Y. As a user of X, Y would prefer to keep the systems named as is. X does it for them anyway and makes a PR. Y rejects the PR. Y does not want this change. Y even believes that X should be motivated to stay backwards compatible because a popular project like Y doesn't want to change. X writes a post smearing Y. X also lambasts the Common Lisp community at large for not jumping in to support X's call for changing Y. I absolutely fail to see how the Common Lisp community is complicit in anything wrong... or anything at all, for that matter. I don't feel like I'm a poor community citizen because I don't get in the middle of my neighbor's disputes with the water company we both use.

brabel 5y ago
It's very common that people take the behaviour of one or two people they actually interact with as the behaviour of the "community". Jumping to conclusions is a favourite past-time. In this case, Y actually affects a lot of members of the community, but I guess most couldn't be bothered to express their opinions. I don't know if the proposed change has strong enough motivation to break backwards compatibility in a language that values backwards compatibility extremely highly (or am I jumping to conclusions too?). But feels like, on the surface, the change is cosmetic and hence uncalled for?
- reikonomusha 5y ago
  A long time ago, countless projects started using X in a way that wasn't documented (specifically, using X to define multiple modules in one file, instead of one module per file), and it has worked forever just fine. I consider it an unintended (and nice) feature. X no longer wants to support this use-case, because they discovered that by not supporting it, they can clean up X's code a bit, and it makes X more efficient at certain tasks. So X turned this into a warning, and is waiting for downstream projects to fix their (new) warnings, before axing this feature. But one popular project, Y, refused to make the change which clears the warning (possibly hoping that X will be more careful to support, not break, idiomatic uses of X). In the end, project Y voluntarily and without friction added a maintainer who would be willing to keep up with these changes (which were considered by Y to be frivolous). Eventually the system was renamed.
  - p_l 5y ago
    I'd like to add that the fact that you're supposed to use only one DEFSYSTEM form per ASD file wasn't very advertised, at least back when I wrote my first ASDF systems (back when ASDF2 was still in the future) and since then one rarely delved again into full rereading of the manual.