Hacker News new | past | comments | ask | show | jobs | submit login

Not really Alpine's problem that there aren't upstream wheels for your dependencies. I think you're being realistic with your suggestion but you're barking at the wrong tree.



Multi-stage container builds are also not exactly unusual. You would generally not want an entire C build system sitting around in your container.


Isn’t this also a problem of requiring the compiler toolchain at install time?

I think we will eventually reach consensus that package managers requiring a compiler is a misfeature.

I think I’d be just fine having two base images, one for runtime, and a superset image for Continuous Integration that layers the compiler toolchain on top.

But Node has this same behavior and it drives me nuts.


>Isn’t this also a problem of requiring the compiler toolchain at install time?

This isn't a new problem if you use docker. To address it you have to either use multistage builds or more traditionally you install the dev tools, build and install your artifacts, then remove your dev tools all in a single step. It's annoying, but it's a common pattern.


> I think we will eventually reach consensus that package managers requiring a compiler is a misfeature

What's your alternative solution? For simple native libraries there's always libffi, but things that need numerical processing will want to actually plug into the underlying value representation directly to not sacrifice speed.


I Agree, since this is the case for all distros using musl. This was a decision made by python to not support musl in the wheel manylinux standard: https://github.com/pypa/manylinux/blob/46241e9debbaf4b045c88...

If you need more than a few packages installed using pip, then Alpine simply is not a good choice for python.


musl seems very niche. That’s an ecosystem problem; that is on Alpine for swimming upstream.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: