←back to thread

272 points abdisalan | 1 comments | | HN request time: 0s | 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 #
regularfry ◴[] No.42181259{3}[source]
My slightly heretical opinion is that Debian would have been better off removing system pip entirely. The system python is for the system.
replies(1): >>42183221 #
j1elo ◴[] No.42183221{4}[source]
My not so heretical opinion is that PIP should behave like NPM by default, and work under a local environment subdirectory, just like "npm install" already creates a "node_modules" directory where to put all files, without the user needing to specify how and where and which env tool to use.
replies(2): >>42184259 #>>42184267 #
1. secondcoming ◴[] No.42184259{5}[source]
Python is a scripting language. I shouldn’t need to faff about with environments if I want to run my script on another machine.