Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A few things to know before stealing my 914 (2022)

hagerty.com

Post reply on HN
Print view View original

181–190 of 190 posts

Re: A few things to know before stealing my 914 (2022)

#181

Post by zahlman »

wtallis wrote: post #178
qwelkfj wrote: post #176

Earlier quoted context omitted.

$ virtualenv ~/venv/yt-dlp $ . ~/venv/yt-dlp/bin/activate $ pip install yt-dlp $ ln -s ~/venv/yt-dlp/bin/yt-dlp ~/bin/yt-dlp $ deactivate $ yt-dlp ...

Isn't that really obviously about five steps too many to be considered a reasonable way of installing a package? (And you didn't handle getting an appropriate version of python installed.)

> Isn't that really obviously about five steps too many to be considered a reasonable way of installing a package?

That's why I use pipx. But the activation and deactivation in that example are completely unnecessary, and the last line is just using the installed package. Installation actually looks like:

  $ python -m venv ~/venv/yt-dlp
  $ ~/venv/yt-dlp/bin/pip install yt-dlp
  $ ln -s ~/venv/yt-dlp/bin/yt-dlp ~/bin/yt-dlp
which is only two steps too many if we acknowledge that there has to be at least one step. This all of course can also just be put in a shell script, or a function in your ~/.bashrc.

Pip just happens to be laser focused on the actual installation of packages, so it doesn't provide that wrapper. (With PAPER I'm aiming for slightly broader scope, but still something intended specifically for users that's only one piece of a developer toolchain.)

> (And you didn't handle getting an appropriate version of python installed.)

When was the last time you tried to obtain an application that could be installed as a PyPI package and your system Python wasn't compatible? Everyone knows the CPython release cadence now and is strongly pressured to advance their own support in lock-step with that. Similarly for libraries. There's already a full set of wheels for the latest version of NumPy for 3.14, 22 of them. Even musl-based distributions are provided for. Even 32-bit Windows is provided for, for those few holdouts.

If your target audience doesn't have Python and understand on a basic level what that is, why will they be able to understand using the uv command line and accept using that to install a program?

Re: A few things to know before stealing my 914 (2022)

#182

Post by zahlman »

timcobb wrote: post #155
tdeck wrote: post #134

Earlier quoted context omitted.

But then all the tool's dependencies have to play nice with the dependencies of all your other unrelated Python-based tools. One thing you can do (I'm not saying it's user friendly) is set up the tool in a virtualenv and then set up an alias like alias foo-tool=/home/blah blah/tools/something/env/bin/python -m foo-tool

But this is true for anything that isn't statically linked?

Why would static linking be necessary? The virtual environment contains all the needed dependencies, and isolates them from everything else.

Re: A few things to know before stealing my 914 (2022)

#183

Post by zahlman »

swiftcoder wrote: post #138
kalaksi wrote: post #128

Earlier quoted context omitted.

I don't get it. Then you just install the tool outside of venv? then it's installed for your user account.

That requires you to be running the right version of python at the system level, and for all your installed tools to have compatible package versions. It doesn't work very often for me

What sorts of things are you installing that you "often" need to care about having the "right" version of Python? It's normal in the Python ecosystem that packages explicitly support every non-EOL Python version. Numpy already has wheels out for 3.14. And even if you use an older Python, the older compatible Numpy versions don't go away.

Can you give a concrete example of an installation you attempted that failed?

Re: A few things to know before stealing my 914 (2022)

#184

Post by swiftcoder »

zahlman wrote: post #183
swiftcoder wrote: post #138

Earlier quoted context omitted.

That requires you to be running the right version of python at the system level, and for all your installed tools to have compatible package versions. It doesn't work very often for me

What sorts of things are you installing that you "often" need to care about having the "right" version of Python? It's normal in the Python ecosystem that packages explicitly support every non-EOL Python version. Numpy already has wheels out for 3.14. And even if you use an older Python, the older compatible Numpy versions don't go away. Can you give a concrete example of an installation you attempted that failed?

It's rarely the python version itself that is the problem (provided everything supports 3.9+ or similarly recent versions).

The package versions are however fraught - our machine learning codebase at work only was stuck on the 1.x versions of numpy for more than a year, as scipy and ultralytics both took forever to upgrade, and that prevented us adopting packages that depend on the 2.x numpy.

Re: A few things to know before stealing my 914 (2022)

#185

Post by YeGoblynQueenne »

arjie wrote: post #58

I could have written this for my Ducati, but they nonetheless stole it, put it on a flatbed, tried to drill the ignition and fuel cap to start it and failed because Ducatis have had immobilizers for decades now . One dreams of a better class of thief but if they had the IQ would they be thieves of a multi-decade-old motorcycle? The tax that morons levy on the rest of us cannot be understated. Look at what these lead-…

I get why you would want to steal a bike like that, but I don't get why, if you did, you would be OK with damaging it so.

Re: A few things to know before stealing my 914 (2022)

#186

Post by zahlman »

swiftcoder wrote: post #184
zahlman wrote: post #183

Earlier quoted context omitted.

What sorts of things are you installing that you "often" need to care about having the "right" version of Python? It's normal in the Python ecosystem that packages explicitly support every non-EOL Python version. Numpy already has wheels out for 3.14. And even if you use an older Python, the older compatible Numpy versions don't go away. Can you give a concrete example of an installation you attempted that failed?

It's rarely the python version itself that is the problem (provided everything supports 3.9+ or similarly recent versions). The package versions are however fraught - our machine learning codebase at work only was stuck on the 1.x versions of numpy for more than a year, as scipy and ultralytics both took forever to upgrade, and that prevented us adopting packages that depend on the 2.x numpy.

The entire point of the virtual environments is that you can have both on your system, as needed, for separate projects.

But the language isn't designed to support multiple versions of the same library in the same runtime environment. If you get them both to load (and there are a lot of ways), they are different libraries (actual different module objects) with different names (or the same name in different namespaces). Packaging tools can't do anything meaningful about this. I write about this on HN more often than I'd like; see e.g. https://news.ycombinator.com/item?id=45467514 . It's also covered in https://zahlman.github.io/posts/2024/12/24/python-packaging-... .

Re: A few things to know before stealing my 914 (2022)

#187

Post by pastage »

rwmj wrote: post #150
pastage wrote: post #146

Earlier quoted context omitted.

Any project written in a language with big user base java, C#, C++, perl, rust even fortran has this problem. The only thing that helps is experience with the language. I very seldom see code that survives ten years, even no deps things fail because your compiler interpreter changes. It is just part of the job. Sure I am not a big fan of C# or PowerShell but a big part is just that I have no experience.

Nope. Python has a habit of regularly breaking working stuff. It's a developer/community problem - the language itself doesn't require it.

I have never been a Python fan, but I wrote my first python application in Zope 26 years ago it still runs. Since then I have touched other things that are much worse not all of them on the list above. My point is that while python may break, other stuff breaks as well.

There are a lot of prototype integration projects in Python though and that is incredibly hard to get running. I know nothing about C# but as Linus Torvalds said the binary compatibility layer for Linux is Win32 because of Steam, so MS has worked on the problem before. Though I would like to point out that when you are talking about prototype integration projects Windows is as bad as Python, I have rebuilt test environment in Windows that had been left to rot for ten years.

So in my work life experience all programming languages suck at this, python might suck less or more but it is more of a skill issues than anything.

Re: A few things to know before stealing my 914 (2022)

#188

Post by pastage »

NetMageSCW wrote: post #169
pastage wrote: post #146

Earlier quoted context omitted.

Any project written in a language with big user base java, C#, C++, perl, rust even fortran has this problem. The only thing that helps is experience with the language. I very seldom see code that survives ten years, even no deps things fail because your compiler interpreter changes. It is just part of the job. Sure I am not a big fan of C# or PowerShell but a big part is just that I have no experience.

That’s not generally true for .Net, though the use of third party libraries could create an issue in some cases. .Net was designed deliberately so that multiple versions could be installed side by side and an executable would pick the version most likely to work based on target version and compatibility. In most cases .Net is also forward compatible so e.g. a .Net 3 app continues to work on a PC where only .Net 4.8 i…

What I mean with "no experience" is that I have never fixed issues with them myself. The amount of hours we were billed internally for fixing a broken .Net app tells me it was not that easy though.

My point is that if you do not know your platform things get complicated, either for yourself or for people that take over after you. For me personally python does not mark it self as extra hard to handle.

Re: A few things to know before stealing my 914 (2022)

#189

Post by SenHeng »

arjie wrote: post #64
roflchoppa wrote: post #63

Earlier quoted context omitted.

do you still ride?

Only e-bikes in the city, haha! Banned by order of the wife since we have a young newborn. "When the kids go off to college" she says knowing full well that I know that 20 years without and getting on in my sixties will kill me instantly.

I stopped riding in my late 30s when I borrowed a friend's 50cc scooter and realised it scared the shit out of me.

Still can't stop turning my head whenever a StreetFighter or 1099 or something passes by.

Re: A few things to know before stealing my 914 (2022)

#190

Post by shermantanktop »

Stratoscope wrote: post #180
shermantanktop wrote: post #168

Earlier quoted context omitted.

Sorry to hear it, but at the same time those are great stories to remember her by. No matter one’s beliefs, we all live on in the memories of those who knew us.

Thank you my friend. Did you ever see the Pixar movie Coco ? I have a feeling you will really enjoy it.

My kids ambushed me with it and I was a complete wreck at the end.
Post reply on HN