Closed proppy closed 8 years ago
You still haven't clearly defined where we draw the line for this variant, though.
For example, I would personally be very surprised to find that this doesn't include g++
, and that personal expectation is going to be different from user to user.
@tianon will update the description.
@tianon I think adding g++ make senses, since some module might be written in C++ with extern "C" symbol to interop with the runtime.
What about the rest of build-essential that come as recommends (which is just manpages manpages-dev
if we ignore the items for making debian packages)? Where do we draw the line?
This issue is related to #16.
Yes, build-essentials without the debian stuff sounds a fine line to draw for me.
Maybe dropping the --no-install-recommends
would make more sense here.
That's great but it's all feelings and impressions. How do we unambiguously state that "this is what's OK to be included" without it being based entirely on our personal feelings for what's "too much" ?
@tianon what do you think for the updated description?
The goal of the variant is to include just enough bytes to cover building native package
The goal should be that if you include a python, node or go package in requirements.txt
, packages.json
or import
that has some C code in it, it should not fail because you miss some elements of the native toolchain.
I think "building native package" is still subjective. I don't think it's at all far-fetched to imagine Python or some other language growing support for native modules written directly in Go. Similarly, what does this mean for LLVM and friends?
@tianon maybe a better way to phrase that would be npm install
or pip install
or go get
should not fail because you miss a tool. Many languages have a document C/API, with clear hook in their build system. The goal here is to define the common set of tool they expect to be there to produce native extension.
Closing stale PR. Most users want something tiny, like an alpine-based image, or want it just to work, like the default language images; shared layers isn't really a concern for most users.
based on the discussion on https://github.com/joyent/docker-node/pull/2#issuecomment-71506264 adding a
-gcc
variant that could share between language stacks with a C API.The goal of the variant is to include just enough bytes to cover building native package: