Hacker News Reader

Comment by deepsun | Hacker News Reader

> it is more common for packages to be distributed in binary form rather than as sources, so you don't run into problems compiling dependencies

Not sure what you mean here. Java bytecode is similar to source code, just easier for machines to parse, also easy to decompile. Mainstream Java is an interpreted language (requires JVM), not compiled.

Don't see what's the difference with packaging, say, python code to a zip archive.

View on HN

I mean that java libraries that do use native code don't ship packages with c source code, that the user is expected to compile locally, as is common in python, ruby, and node. But instead they typically have a jar that includes a pre-compiled binary library, or several to support multiple platforms. So as long as you are using one of the supported platforms, it just works. But if you are on a platform that doesn't have a pre-compiled library, you will probably need to build the package yourself.

Its relatively common in Python for C/C++ code to be shipped pre-compiled as part of binary wheels (for at least the most common architectures). You do still end up falling back to sdists if your Python version or OS don't line up with any of the supplied binary wheels from the author. e.g. take a look at the pre-compiled set for pydantic-core https://pypi.org/project/pydantic-core/#files

Gotcha, yes, in my experience as long as a python library installs as a prebuilt wheel (.whl), then it's ok. If it tries to compile on my machine (setup.py) -- it never is able to.

Reply on news.ycombinator.com