RFC: StdBinDeps package ?

[samoconnor]

What if there was a StdBinDeps package?

This package would contain no Julia code (except maybe for test code?) but would provide a standard set of binary libraries.

I am guessing that a small-ish set of "standard" libraries could be defined that would satisfy the binary requirements of the most commonly used Julia packages.

Some advantages:

1. Many package authors could avoid dealing with BinDeps and just put StdBinDeps in REQUIRE.
2. Package authors using StdBinDeps would not have to worry about supporting new platforms later. Any time a new platform is added to StdBinDeps (e.g. AWS Lambda, or Android, or WSL), all the client packages should just work.
3. For platforms where the BinDeps are build from source, building them all at once avoids problems of version and comile-time-feature-configuraiton inter-dependency.
4. Pre-built and pre-tested StdBinDeps for common platforms could make deployment of CI sandboxes faster and simpler.
5. If StdBinDeps was included with the default ordinary-user-installer then doing Pkg.add would be smoother more of the time for ordinary users.
6. Flexibility in how BinDeps are satisfied. e.g.: A pre-compiled set of binaries for Windows and Mac installers. For user-controlled Linux desktops use apt or yum. For Linux systems where users have non-privelaged accounts, build local copies. For embedded or containerised cloud deployments, build everything from source on a build box (See Building Cairo.jl for AWS Lambda JuliaGraphics/Cairo.jl#133).

Possible list of standard libraries:

cairo
crypto
fontconfig
freetype
gettext
gobject
liba
libcurl
libffi
libflac
libglib2
libhttp_parser
libogg
libopenssl
libpng
libvorbis
libxml2
mbed
mbed_crypto
mbed_x509
nettle
pango
pangocairo
pixman
zlib

[tkelman]

Pretty arbitrary list. No ZMQ? The problem with coming up with a "standard" list is no one can agree what does or does not belong in it. This way Conda leads. Improvement is needed w.r.t. BinDeps, but I'm not sure centralization is the answer.

edit: Given this isn't actionable in base I think we should close it for now, but discussion can continue here (or probably better, on julia-dev) and we could reopen if anything needs to be changed in Pkg etc. If this would be worth your time to work on, go for it, and feel free to advertise to other package authors who may find it useful. Bundling too many dependencies together does sort of defeat the purpose of package management though.

[nalimilan]

It would be more natural for each Julia package wrapping a library to take care of installing/building it. Package authors then simply need to add the wrapper to their REQUIRES. That also reduces the amount of data to download everytime one of the libraries is updated.

[ViralBShah]

I am not sure I like this. This doesn't prevent anyone from creating such a package, but I certainly do not want a StdBinDeps dependency to bring in all the cairo libraries.

[lobingera]

This looks seriously like an OS package management task, not a julia task. While i agree there is interaction between julia packages and library package management in e.g. BinDeps.

-1

[JeffBezanson]

I think any problems with BinDeps should be addressed case-by-case. I don't see a fundamental reason getting native libraries as-needed can't work.