Post B6o9acbu4NVMETxwrA by mirabilos@toot.mirbsd.org
 (DIR) More posts by mirabilos@toot.mirbsd.org
 (DIR) Post #B6nuqcgU422DmaHRVQ by arclight@oldbytes.space
       0 likes, 0 repeats
       
       So today is the end of the month. A number of our reports are due today, at least three (I'm reviewer on two). IT is patching everything right now. They uninstalled Python 3.11 from production servers without telling anyoneThe last three words of the previous sentence are the important ones. The rest are important too but are substantially less critical without those last three.So a post-processor I'm responsible for broke because it's installed in a Python 3.11 virtual environment as is good practice to avoid multiple applications fighting over dependencies under one interpreter. The application is distributed as a .whl as is good practice - it requires the least effort on end users while maintaining good configuration management.The application's runtime and development dependencies are listed in the project's pyproject.toml file as is modern practice. The appropriate requirements.txt files are created by pip-compile which also point pip to pull dependencies from our local PyPi repo, again good practice for configuration management, security, etc.Unfortunately, pip-compile does not honor ">=" as specified in pyproject.toml, it pins dependencies with "==". This great if that's what you want; this is a post-processor and we're mostly concerned that it run, not that it's installed with specific versions of dependencies.I clone the post-processor's repo, build a Python 3.13 virtual environment with the intent of refreshing the requirements.txt files to work with 3.13 compatable dependencies.pip-compile doesn't work, throwing a cryptic use_pip517 error so regenerating the requirements files won't work. So I try to install the existing requirements files. I do not expect this to work so I am not surprised when every third dependency breaks because the pinned version is incompatible or we don't have the platform- and Python-version-specific .whl in our local repo.The solution was to bump the project version and strip all the version numbers off everything in the requirements.txt files so it installs whatever version it can. I'm still left with no way to build version-aware requirements.txt files because of the should-not-be-my-problem use_pep517 problem. For the moment I'm ignoring the build system shrieking about SPDX license tags (you know what license SPDX doesn't list? "Other/Proprietary"! Do you know what all of my work code is licensed as? That's exactly right! I've sorted this BS out on other projects so this is also not a surprise to me.I think that going forward I will be writing all my utilities in Rust. Or Zig. Or D. Or Spark/Ada. Anything but Python. Good practice won't save you and the project risk is simply not worth the convenience of Python. In our environment I no longer consider it git for use. There might have been a graceful way forward had IT given us sny warning they were going to break Python on the production servers but they didn't. I can't change or fix our IT department (or the whole benighted industry), I can't fix Python but I sure as hell can replace it with something that doesn't self-destruct every fiscal quarter.A post-processor like mine does not change unless it needs to change. It may not get a change for *years* and that is reasonable for this software in this environment. Nothing says you as a developer and the projects you work on are disposable quite like the Python ecosystem does. It's a huge middle finger every time I fire up Python and find that half a dozen things are broken with no documentation or migration path. Nothing about Python compensates for this absolute lack of dependability. I just can't trust it, I just can't.
       
 (DIR) Post #B6nuqd4Edj28yFOPWi by mirabilos@toot.mirbsd.org
       1 likes, 0 repeats
       
       @arclight oh, TIL that SPDX only considers free-ish licences instead of a machine-readable indicator for all kinds of licences used around software and the likes.OK, I’m going to call everyone proposing use of anything SPDX-adjacent in a business context a fool now.
       
 (DIR) Post #B6nuqe5gpnn89355Qu by arclight@oldbytes.space
       0 likes, 0 repeats
       
       Addendum: You'll note that I did not describe any of the code changes I needed to make because of the change from 3.11 to 3.13. That's because the application source code didn't change at all - all that changed was a version bump in pyproject.toml and removal of version numbers from requirements.txt. Maybe if this inconvenience only affected me it might be tolerable but I had an engineer, his manager, and his manager affected by an outage that should not have happened. That's unacceptable project risk.
       
 (DIR) Post #B6o9acN0xjaxUJ03eK by arclight@oldbytes.space
       0 likes, 0 repeats
       
       @mirabilos It costs them _nothing_ to include a generic other/proprietary license or for Python's build system to just mark the package as other/proprietary if no SPDX license tag was found. I could easily mark a package with the appropriate license prior to the build system metadata change. Finding useful documentation on how to create a custom license tag is difficult/impossible the guidance provided is vague and does not match what the build system expects to see in pyproject.toml. It's infuriating and stupid for packages that built fine with metadata two months ago won't build now and provide no migration docs. Not a problem with code, just metadata, and this is a glaringly obvious problem that should have been detected and fixed before release. SPDX could fix it easily if they wanted, someone other than me probably told them about it years ago and they took no action. Similarly whoever made the decision to change the expectations of pyproject.toml had to know that "Other/Proprietary" is the _default_ if no other license is specified. I can't believe this is a simple oversight - if they can't do this trivial thing right, how can I trust them with more important tasks. It's either doctrinairre BS ("we won't acknowledge that anything but FLOSS licenses exist") or bucket-on-head willful policy blindness ("we're just implementing the PEP to the letter; if it breaks in common use cases, that's not our problem. We implemented the PEP and only the PEP")
       
 (DIR) Post #B6o9acbu4NVMETxwrA by mirabilos@toot.mirbsd.org
       0 likes, 0 repeats
       
       @arclight I was looking into this inspired by your post, pondering if I could submit a specific proprietary licence block to SPDX for listing (one I’ve found in several old places over the years), but their guidelines apparently say they’re only interested in free-ish licences (yet they do list the Restricted Commons ones… hypocrites…)Python build systems are insane and have just gotten more complex and worse…