3 ms·

Reminds me of two days of bug fixing, after our Python mapping tool suddenly returned bogus data, without any change in the code base. Turns out, we did not pi

Reminds me of two days of bug fixing, after our Python mapping tool suddenly returned bogus data, without any change in the code base. Turns out, we did not pin the pyproj library [1] and they introduced a switch from lon-lat to lat-lon order, per default. It was possible to retain the old behavior with `always_xy: bool = False`. I saw hundrets of similar reports, who knows how many users were effected. Conclusions, a) Always pin your dependencies, b) explicit is better than implicit. Besides, I have a personal, subjective preference for lon-lat, but I understood the lat-lng order to be the officially accepted norm. [1]: https://pyproj4.github.io/pyproj/stable/api/proj.html https://pyproj4.github.io/pyproj/stable/api/proj.html

cozzyd 5y ago
That is awful. They should have changed the method name with such an abusive change.
- Helmut10001 5y ago
  Looked it up, just to prevent that the pyproj team gets blamed for this: The change in behaviour was actually introduced in the PROJ library, which is used by pyproj. This is the specific merge with some additional discussion [1]. The basic motivation was that PROJ was changed to correctly follow the axis order of EPSG codes. Anyway, it was quite confusing at that time, but over the years working with geographical data made more sense to me and I am now always aware of the specific order. See also an extended discussion here [2] [1]: https://github.com/OSGeo/PROJ/pull/1182 https://github.com/OSGeo/PROJ/pull/1182 [2]: https://pyproj4.github.io/pyproj/stable/gotchas.html#axis-order-changes-in-proj-6 https://pyproj4.github.io/pyproj/stable/gotchas.html#axis-or...
  - cozzyd 5y ago
    And it looks like indeed, like proj, pyproj updated the major version number when this happened at least. Still think the API should have changed... edit: it does seem like PROJ DID introduce a new header file with a new API[0] and eventually deprecated the older one sometime later, handling the transition much more gracefully. I guess pyproj didn't do the same thing? [0]: https://proj.org/development/migration.html#api-migration https://proj.org/development/migration.html#api-migration
    - notimetorelax 5y ago
      Ah, well here comes the problem - if your dependency changes a major version but your code seems to continue to run correctly, i.e. tests pass, how much more time do you need to spend to investigate the cause for the major version change? I think this example exposes the futility of semantic versioning.
      - cozzyd 5y ago
        Yeah, PROJ handled this correctly, introducing a new header file and eventually deprecating the old one after a while, making it hard to do the wrong thing. But for some reason pyproj must have kept the same interface across the breaking change?
        notimetorelax 5y ago
        In general I agree but I'm making an argument that a non-functional change for you may be a functional change for your users.
      - dragonwriter 5y ago
        > Ah, well here comes the problem - if your dependency changes a major version but your code seems to continue to run correctly, i.e. tests pass, how much more time do you need to spend to investigate the cause for the major version change? You need to investigate the reasons for a major version change before updating the dependency and running tests any time one occurs, to see if any documented behavior you are expecting has changed.
      - Helmut10001 5y ago
        Indeed, this was entirely our fault and as I said, we should have correctly pinned, at least the major version. Our tests did not catch the specific issue, because all code worked - just the output looked scrambled. There are tests that could catch this issue, but we did not anticipate it and therefore had no tests prepared.
        5y ago

cozzyd 5y ago

That is awful. They should have changed the method name with such an abusive change.

Helmut10001 5y ago
Looked it up, just to prevent that the pyproj team gets blamed for this: The change in behaviour was actually introduced in the PROJ library, which is used by pyproj. This is the specific merge with some additional discussion [1]. The basic motivation was that PROJ was changed to correctly follow the axis order of EPSG codes. Anyway, it was quite confusing at that time, but over the years working with geographical data made more sense to me and I am now always aware of the specific order. See also an extended discussion here [2] [1]: https://github.com/OSGeo/PROJ/pull/1182 https://github.com/OSGeo/PROJ/pull/1182 [2]: https://pyproj4.github.io/pyproj/stable/gotchas.html#axis-order-changes-in-proj-6 https://pyproj4.github.io/pyproj/stable/gotchas.html#axis-or...
- cozzyd 5y ago
  And it looks like indeed, like proj, pyproj updated the major version number when this happened at least. Still think the API should have changed... edit: it does seem like PROJ DID introduce a new header file with a new API[0] and eventually deprecated the older one sometime later, handling the transition much more gracefully. I guess pyproj didn't do the same thing? [0]: https://proj.org/development/migration.html#api-migration https://proj.org/development/migration.html#api-migration
  - notimetorelax 5y ago
    Ah, well here comes the problem - if your dependency changes a major version but your code seems to continue to run correctly, i.e. tests pass, how much more time do you need to spend to investigate the cause for the major version change? I think this example exposes the futility of semantic versioning.
    - cozzyd 5y ago
      Yeah, PROJ handled this correctly, introducing a new header file and eventually deprecating the old one after a while, making it hard to do the wrong thing. But for some reason pyproj must have kept the same interface across the breaking change?
      - notimetorelax 5y ago
        In general I agree but I'm making an argument that a non-functional change for you may be a functional change for your users.
    - dragonwriter 5y ago
      > Ah, well here comes the problem - if your dependency changes a major version but your code seems to continue to run correctly, i.e. tests pass, how much more time do you need to spend to investigate the cause for the major version change? You need to investigate the reasons for a major version change before updating the dependency and running tests any time one occurs, to see if any documented behavior you are expecting has changed.
    - Helmut10001 5y ago
      Indeed, this was entirely our fault and as I said, we should have correctly pinned, at least the major version. Our tests did not catch the specific issue, because all code worked - just the output looked scrambled. There are tests that could catch this issue, but we did not anticipate it and therefore had no tests prepared.
      - 5y ago