←back to thread

272 points abdisalan | 8 comments | | HN request time: 0.632s | source | bottom
1. RadiozRadioz ◴[] No.42183900[source]
I call this phenomenon "node rot". Judging by the comments here, it seems like a universal experience.

My favorite is the way that Python projects rot. Not only does Python's setuptools give you all the fun that node-gyp does, the common practice of versioning packages with packagename>=1.25.5 means you're almost guaranteed breakages as pip installs newer versions of packages than what the project was built with.

replies(4): >>42184392 #>>42185344 #>>42191174 #>>42201978 #
2. gre ◴[] No.42184392[source]
I just today tried reviving an old v12.4 node project and node-gyp is trying to use python2 which I don't even have on my Macbook anymore.
replies(1): >>42188791 #
3. lexlambda ◴[] No.42185344[source]
And project specifying "requires python 3.X+" instead of Version X to Y is also a major culprit I often encounter.

Most of the times it will not work with the newest shiny python, which I only notice after already installing it and then having searched search the Github issues.

replies(1): >>42209854 #
4. ziml77 ◴[] No.42188791[source]
That Python 2 crap hit me as well when working on an older project. It used node-sass which depended on node-gyp. Dealing with upgrading that was a pain because I had to upgrade so much more to get versions of everything that played nice together.

What really pissed me off about it was that Python 2 was already known to be nearing EOL when our project was started, so node-gyp should have been upgraded to work with Python 3 by then. And even more annoying was that node-gyp already had Node to run on, so why in the world was it coded to depend on Python at all!?

5. vivzkestrel ◴[] No.42191174[source]
did you experience this breakage using poetry too?
6. FireInsight ◴[] No.42201978[source]
Oh, one of the worst forms of torture is definitely trying to get a random Python AI project from GitHub running locally. There's almost always a conflict between versions Python, Cuda, Pytorch, and a hodgepodge of pip and conda packages. Publishing a requirements.txt is the bare miminum everybody usually does, but that's usually not enough to reconstruct the environment. The ecosystem should just standardize to using declaratively prebuilt container environments or something.

Granted, my experience is mostly from the GPT-2 era, so I'm not sure if it's still this painful.

replies(1): >>42213882 #
7. __MatrixMan__ ◴[] No.42209854[source]
That happens to me all the time. It helped cement my habit of binding the python version to the project with direnv and a flake.nix so I end up switching to the right version when I cd to the project dir.
8. phatskat ◴[] No.42213882[source]
Don’t know if this would help your case or not, but jart’s llamafile seems like it would be useful

[6] https://github.com/Mozilla-Ocho/llamafile