Dependencies vs. splitting plugin builds

[Marek Libra]

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

[Stef Walter]

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