Reiterating my comment on the MP, I agree with Marco that, due in part to the fixed-point usage pattern of charm-helpers and in part to the specifics of the change, I don't see it as having much potential for breakage.
That said, I'm certainly not against testing it before merging. On Thu, Nov 20, 2014 at 1:25 PM, Marco Ceppi <ma...@ondina.co> wrote: > I have to disagree slightly, currently (and thankfully?) the current way > most charm-helpers aim to be included in charms is by embedding a working > snapshot of that version of charm-helpers. So merging this wouldn't affect a > huge number of charms, instead maybe the 5 or 6 at most that download from > pypi and of those none may actual be broken. As we rethink the distribution > model for charm-helpers (making it a debian package, having actual releases, > etc) this would certainly become a larger concern. The changes look good at > my cursory check, and I hope to review in more detail later this week. > > That said I just wanted to point out that I don't think a change, even as > "drastic" as this would have a huge effect on the ecosystem. As charm > authors sync charm-helpers they'll end up in our testing environment and > should be caught then. > > Marco > > On Thu Nov 20 2014 at 12:33:55 PM Charles Butler > <charles.but...@canonical.com> wrote: >> >> Jay, >> >> I think you're touching on some important topics. Tuning and optimizing >> charm installation without fetching tons of extra packages around an install >> is certainly something I'm very open to experimentation with. >> >> This particular merge makes me suggest we run this through the gauntlet of >> testing scenarios - as if we merge this as is it effects the default >> expected behavior of the apt_install, with > 200 charms in the store - and >> im' going to venture to guess ~ 40% of those are python and charm-helpers >> based charms. This means a very expensive test would follow to ensure we >> don't break whats in the wild. If you were to refactor this to make that a >> parameter on apt_install, and leave the default behavior as is - I would be >> more confident in making the merge happen. >> >> >> All the best, >> >> Charles >> >> >> On Wed, Nov 19, 2014 at 6:27 PM, Jay Wren <jay.w...@canonical.com> wrote: >>> >>> Greetings, >>> >>> I wanted to bring attention to a pending MR >>> https://code.launchpad.net/~evarlast/charm-helpers/use-no-install-recommends/+merge/242270 >>> which I feel can help charm-helpers. >>> >>> By not installing recommended packages, charms will install packages >>> faster, with less unneeded packages. >>> >>> This leads to faster deploys and faster experience for new users and an >>> overall better feeling about juju. >>> >>> On a similar subject, I am asking for feedback from charm-helpers users >>> regarding apt related activity. I feel it might make sense use apt_pkg for >>> as many operations as possible. Would a merge request of this nature be >>> considered or is fork and exec to the more familiar system commands >>> preferred? >>> >>> Thanks, >>> -- >>> Jay >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
