5 ms·

> To date the only examples of this done with a measure of effectiveness are actually entire operating system distributions backed by software like apt, yum, pk

> To date the only examples of this done with a measure of effectiveness are actually entire operating system distributions backed by software like apt, yum, pkg-src, etc. npm seems to handle this just fine for both JS and native (c++) node modules via gyp, and it's officially supported on at least three platforms (Windows, Linux, OS X) using 3 different compilers AFAIK (microsoft c/c++, gcc and clang respectively). Granted, node enforces specific conventions for packaging and lookup (package.json and node_modules), but there's no reason similar conventions can't be created for C/C++ modules, even if they're more complicated due to language specific complexity (dynamic vs static linking). Mantaining packages up to date for a lot of open source projects could be done by a sufficiently dedicated community.

haberman 11y ago
> npm seems to handle this just fine for both JS and native (c++) node modules via gyp Could you describe this in a bit more detail? Does gyp (in the context of npm) build the binaries at install time, or is it a repository of a bunch of pre-built artifacts? In my experience of installing npm packages, it doesn't seem like it's building native extensions at install time, but it's hard to say for sure.
- voltagex_ 11y ago
  It depends. Someone more experienced may be able to add more info, but gyp appears to know what is available pre-built vs what needs to be built. Depending on what platform and options you've selected it might call (for example) the Visual Studio C compiler to build a native extension for you.
- rpedela 11y ago
  Binary modules are usually built at install time.
- TheCoreh 11y ago
  It does build them on install time, if a suitable compiler is available. A classic example is the `ws` module (WebSockets), when you install that you'll normally see the build log for its native dependencies on the npm output: $ npm install ws > bufferutil@1.2.1 install /Users/coreh/Projects/test/node_modules/bufferutil > node-gyp rebuild CXX(target) Release/obj.target/bufferutil/src/bufferutil.o SOLINK_MODULE(target) Release/bufferutil.node > utf-8-validate@1.2.1 install /Users/coreh/Projects/test/node_modules/utf-8-validate > node-gyp rebuild CXX(target) Release/obj.target/validation/src/validation.o SOLINK_MODULE(target) Release/validation.node /Users/coreh/Projects/test └─┬ ws@0.8.1 ├─┬ bufferutil@1.2.1 │ ├── bindings@1.2.1 │ └── nan@2.1.0 ├── options@0.0.6 ├── ultron@1.0.2 └── utf-8-validate@1.2.1
ossreality 11y ago
The idea of looking at npm for any sort of guidance on how to properly do package management is the most insane thing I've heard in recent memory.
eropple 11y ago
> there's no reason similar conventions can't be created for C/C++ modules "Oh, that's cute, you want me to do that instead of work on my project?" There's a huge first-mover disadvantage to this that has to be solved.

haberman 11y ago

> npm seems to handle this just fine for both JS and native (c++) node modules via gyp Could you describe this in a bit more detail? Does gyp (in the context of npm) build the binaries at install time, or is it a repository of a bunch of pre-built artifacts? In my experience of installing npm packages, it doesn't seem like it's building native extensions at install time, but it's hard to say for sure.

voltagex_ 11y ago
It depends. Someone more experienced may be able to add more info, but gyp appears to know what is available pre-built vs what needs to be built. Depending on what platform and options you've selected it might call (for example) the Visual Studio C compiler to build a native extension for you.
rpedela 11y ago
Binary modules are usually built at install time.
TheCoreh 11y ago
It does build them on install time, if a suitable compiler is available. A classic example is the `ws` module (WebSockets), when you install that you'll normally see the build log for its native dependencies on the npm output: $ npm install ws > bufferutil@1.2.1 install /Users/coreh/Projects/test/node_modules/bufferutil > node-gyp rebuild CXX(target) Release/obj.target/bufferutil/src/bufferutil.o SOLINK_MODULE(target) Release/bufferutil.node > utf-8-validate@1.2.1 install /Users/coreh/Projects/test/node_modules/utf-8-validate > node-gyp rebuild CXX(target) Release/obj.target/validation/src/validation.o SOLINK_MODULE(target) Release/validation.node /Users/coreh/Projects/test └─┬ ws@0.8.1 ├─┬ bufferutil@1.2.1 │ ├── bindings@1.2.1 │ └── nan@2.1.0 ├── options@0.0.6 ├── ultron@1.0.2 └── utf-8-validate@1.2.1

ossreality 11y ago

The idea of looking at npm for any sort of guidance on how to properly do package management is the most insane thing I've heard in recent memory.

eropple 11y ago

> there's no reason similar conventions can't be created for C/C++ modules "Oh, that's cute, you want me to do that instead of work on my project?" There's a huge first-mover disadvantage to this that has to be solved.