News for hackers. Stuff that matters.
Re:Bundling binary tools in Python wheels by epistasis on Friday June 17, 2022 @10:25AM (#31778683)
About 10 years ago, before Docker, and before (I knew about?) conda, I was using Python packages with binaries inside to create reproducible virtual environments with consistently versioned binary tools to go along with all our Python code. We were avoiding virtualization and running on bare metal so this was the best way to distribute code across a cluster.

I added small setup.py scripts to a dozen open source C and Java packages, and deposited them on an internal package server.

It worked OK, and unlike Conda, to this day you can still run an install without burning through CPU-hours of SAT-solving.

Biggest problem was if there were packages that wanted different versions of the same dependency.

Re:Bundling binary tools in Python wheels by divbzero on Friday June 17, 2022 @12:24PM (#31780548)
> Biggest problem was if there were packages that wanted different versions of the same dependency.

How often and in what contexts would you encounter this version dependency issue? Was there a good solution or would you work around the issue by finding compatible versions?

Re:Bundling binary tools in Python wheels by epistasis on Friday June 17, 2022 @01:27PM (#31781437)
This never presented a real problem in practice, but IIRC pip just silently installs over the other version.

And since we had a closed system, it was entirely on us to set it up correctly. It was just a discovery a couple years in that we hadn't properly thought of ahead of time.

Re:Bundling binary tools in Python wheels by prpl on Friday June 17, 2022 @10:45AM (#31778959)
FWIW conda has mamba as an option now which (mostly) fixed the slow SAT silver
Re:Bundling binary tools in Python wheels by epistasis on Friday June 17, 2022 @11:04AM (#31779262)
Mamba is completely unusable for me too.