Hi,
I was further thinking about splitting the core cockpit and the recent 'pkg' plugins to allow independent build for each of them. I would expect that plugins will share same set of run/build dependencies and I don't think the 'first class' plugins shall maintain their dependencies on its own.
I think it would be beneficial to define (and further maintain) shared set of nodejs/bower deps as separate .rpms (or .debs), like cockpit-nodejs-...rpm - just nodejs cockpit-nodejs-modules-...rpm - all node_modules cockpit-bower-...rpm - tentative, probably deprecating in favour of nodejs/webpack
The build will require these packages. The resulting source tarball(s) will be much smaller since just the sources and not dependencies will be included. Potential licence issues can be solved just once.
There will be still control over dependencies but with more flexibility.
Any ideas? Thanks, Marek
On 26.05.2016 14:56, Marek Libra wrote:
Hi,
I was further thinking about splitting the core cockpit and the recent 'pkg' plugins to allow independent build for each of them. I would expect that plugins will share same set of run/build dependencies and I don't think the 'first class' plugins shall maintain their dependencies on its own.
We've started to incubate such dependencies in the lib/ directory of the Cockpit tree. These are bundled dependencies that go into the various 'pkg' plugins.
I think it would be beneficial to define (and further maintain) shared set of nodejs/bower deps as separate .rpms (or .debs), like cockpit-nodejs-...rpm - just nodejs cockpit-nodejs-modules-...rpm - all node_modules cockpit-bower-...rpm - tentative, probably deprecating in favour of nodejs/webpack
Yup, I think that makes sense. The first step is moving the common code into lib/ and using it during bundling and building of the various 'pkg' plugins.
cockpit.js and some of the core that remains in base1 is an exception to this effort. It now has stable API, but the implementation may need to change behind the API over time. So it makes sense to load from a common source, and not use bundling.
The build will require these packages. The resulting source tarball(s) will be much smaller since just the sources and not dependencies will be included. Potential licence issues can be solved just once.
There will be still control over dependencies but with more flexibility.
I think this makes sense. So I guess my question is, beyond the effort that's going on so far (see the various pull requests) ... and Lars's work on using webpack ... what's the next step here? Is there a concrete section of code that would be worth using as our guinea pig for this?
Stef
cockpit-devel@lists.fedorahosted.org