←back to thread

272 points abdisalan | 5 comments | | HN request time: 0.002s | source
Show context
mvkel ◴[] No.42175730[source]
> time to run it after not touching it for 4 years

> Two hours of my life gone...

Two hours of work after 4 years sounds ... perfectly acceptable?

And it would have run perfectly right away if the node version was specified, so a good learning, too

This feels like making a mountain out of a mole hill

replies(21): >>42175799 #>>42175818 #>>42175826 #>>42175846 #>>42176217 #>>42176305 #>>42176788 #>>42176958 #>>42181497 #>>42182299 #>>42182564 #>>42182778 #>>42183020 #>>42183093 #>>42183501 #>>42183725 #>>42184814 #>>42192770 #>>42193606 #>>42194518 #>>42211558 #
fourseventy ◴[] No.42176305[source]
Sounds like you are way too used to the javascript ecosystem if you think getting an old project to build should take hours...
replies(4): >>42176343 #>>42176528 #>>42185263 #>>42185292 #
Ameo ◴[] No.42176528[source]
What ecosystem are you comparing to?

Any C/C++ project with even mild complexity has a good chance of being extremely difficult to build due to either missing libraries that have to be installed manually, system incompatibilities, or compiler issues.

Python has like 28 competing package managers and install options, half of which are deprecated or incompatible. I can't even run `pip install` at all anymore on Debian.

Even Rust, which is usually great and has modern packaging and built-in dependency management, often has issues building old projects due to breaking changes to the compiler.

All this is to try to say that I don't think this is some problem unique to JS at all - but rather a side effect of complex interconnected systems that change often.

A big reason Docker and containers in general became so popular was because it makes this problem a lot less difficult by bundling much of the environment into the container, and Docker is very much agnostic to the language and ecosystem running inside it.

replies(6): >>42178164 #>>42179805 #>>42180587 #>>42181310 #>>42184179 #>>42191776 #
elashri ◴[] No.42179805[source]
You can't use 'pip install' in debian because they chose to do that during the transition from python2 to python3. You should use 'pip3 install' which is provided by package python3-pip from debian.

One can argue that this decision should be revised by debian but you should not install packages on system python installation for working into projects. Always use virtual environment.

replies(1): >>42180222 #
Ameo ◴[] No.42180222[source]
No that does not work either. You get an error like this:

» pip3 install supervisor error: externally-managed-environment

× This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install.

As far as I can understand, they did this on purpose to dissuade users from installing packages globally to avoid conflicts with other Python environments.

Anyway, I'm not trying to argue about if that decision is right or not - I just wanted to use it as an example for my case that the JS ecosystem isn't alone and may even be far from the worst when it comes to this kind of issue.

replies(3): >>42181070 #>>42181259 #>>42184227 #
1. elashri ◴[] No.42181070{3}[source]
I understand that, you can use `--break-system-packages` or change configuration `python3 -m pip config set global.break-system-packages true`.

Python is different here because in many linux distributions, there are many tools that rely on you system python. Python unlike node is not limited (in practice) to web applications. that's why you have to be more careful. So while I understand you are using this as an example, I don't feel that your comparison is apple to an apple.

replies(1): >>42183091 #
2. LamaOfRuin ◴[] No.42183091[source]
>Python unlike node is not limited (in practice) to web applications. that's why you have to be more careful.

They may or may not be running Node.js specifically, but I believe that many Linux distributions, as well as Windows, include JavaScript code in core applications. I don't see this as particularly different, except that they might choose to assume a single standard system Python that is able to be modified by standard Python development, whereas I would rarely expect that to be the case with however each component chooses to execute JavaScript.

replies(1): >>42183491 #
3. elashri ◴[] No.42183491[source]
Apps that rely on OS provided Webview and electron apps are totally different situation. This is exactly what I said. And no, they don't use any standard nodejs installation like python. And they are different as I said. so this is still apples to orange comparison.
replies(1): >>42183642 #
4. LamaOfRuin ◴[] No.42183642{3}[source]
>Apps that rely on OS provided Webview and electron apps are totally different situation.

No, they're not. I'm talking about core apps and services that are essential to a functional operating system. This is exactly the same situation. The difference is choices made by the OS and language ecosystem about how to manage dependencies in various use-cases. It is an apples to oranges comparison because of those decisions and not because of the language.

replies(1): >>42189302 #
5. jcelerier ◴[] No.42189302{4}[source]
Which apps would that be ? I'm pretty sure there's zero node server running on my desktops & laptops at the moment