3 ms·
> Why? Node's packaging story is about a million times better than Python's. You literally just listed some of the issues with Python, none of which apply to No
by sgarland 3y ago
> Why? Node's packaging story is about a million times better than Python's. You literally just listed some of the issues with Python, none of which apply to Node.
No, instead you get to deal with absurdly slow dependency solving / installation (I gather Bun is fast, so good on that guy), the existence of leftpad, and a `node_modules` directory that is stupidly large.
> Not an issue. [to let as few things as possible interact with system Python.]
Obviously, because systems aren't issuing tooling in Node.
> Node has one way to install things and it isn't the way that nobody has heard of (I honestly had not heard of pipx until now and I'm forced to write Python some of the time for my job).
This is literally untrue – I know for a fact that both npm and yarn are extremely popular, and as mentioned, the newcomer bun exists.
> How about knowing to use `--config-settings editable_mode=compat` in order to use editable installs with static tooling?
Or, you know, switch to modern solutions for this: `poetry add --path /foo/package` or `pipenv install -e /foo/package`.
> Oh and don't forget the whole `pip3`/`python3 -m pip` debacle. Did I say `python3`? I meant `python3` except on Windows.
Don't use Windows, obvs. Seriously though, I give absolutely zero fucks about development experience on Windows with Python.
- FridgeSeal 3y ago> No, instead you get to deal with absurdly slow dependency solving / installation …have you installed anything with Python recently? It’s not exactly speedy itself. Oh and who knows whether said application will do the right thing and use a venv or just spew its packages into the global path. At least node has the dignity to put all its project-scoped dependencies into a single place, separate from everything else. > Obviously, because systems aren't issuing tooling in Node. Given I can’t remember the last time I used an application that relied on the system providing the runtime (let alone the correct version) instead of shipping their required version, I’m not sure this is really much of a point. > This is literally untrue – I know for a fact that both npm and yarn are extremely popular, and as mentioned, the newcomer bun exists. And all of them are more streamlined than your average Python packaging experience, I promise. I could probably get my parents to NPM install a working with greater success and ease than trying to get them to do the same with whatever is the latest Python packaging mechanism de jour.
- sgarland 3y agoI have to ask, to clarify some points: are you referring to a library for use in a project, or a standalone tool? > have you installed anything with Python recently? It’s not exactly speedy itself Yes? I’ve never thought, “man this is slow,” which is very unlike my few experiences with npm. IIRC yarn was quite a bit faster, but I haven’t used either in some time. If you have a list of packages as a benchmark, I’m happy to try to come up with an equivalently-sized Python list and compare the two. > Given I can’t remember the last time I used an application that relied on the system providing the runtime (let alone the correct version) instead of shipping their required version, I’m not sure this is really much of a point. I think you’re missing the point – systems often ship with tooling written in Python because it’s a reasonable language, with a relatively stable ecosystem. Python versions don’t EOL for at least 5 years. Node is about half that.
- IshKebab 3y ago> No, instead you get to deal with absurdly slow dependency solving / installation NPM is definitely faster than pip to install things. Not sure what you're talking about here. > I know for a fact that both npm and yarn are extremely popular The point is they both work. Nobody is going to say "you picked the wrong package manager out of these 8 options". There's an obvious option and a slightly less obvious option and they both work properly. > switch to modern solutions for this What was I just saying about having to magically know the "right" way to do it? In any case I don't think either of those will solve the issue. > Don't use Windows, obvs. Seriously though, I give absolutely zero fucks about development experience on Windows with Python. Sounds like you give zero fucks about the Python development experience on Linux too, otherwise you wouldn't defend its obvious deficiencies.