workers using *state.State

[Andrew Wilkins]

On Wed, Sep 9, 2015 at 6:14 AM Ian Booth <ian.booth at canonical.com> wrote:

> Those workers below aren't the only ones. There's also minunits and
> peergrouper
> workers.
>
> No-one does these things on purpose. Just last week I caught and rejected
> a pull
> request to introduce a new worker depending on state directly. People make
> mistakes. Perhaps we should introduce a test which fails if state is
> imported
> into any worker code. We have similar tests already for other forbidden
> imports.
>

+1. I was thinking the same thing, and eventually that test should be
increased to other packages too.

On 08/09/15 17:12, William Reade wrote:
> > People keep writing them, in defiance of sane layering and explicit
> > instructions, for the most embarrassingly trivial tasks
> > (statushistorypruner? dblogpruner? txnpruner? *all* of those can and
> should
> > pass through a simple api facade, not just dance off to play with the
> > direct-db-access fairies.)
> >
> > There is no justification for *any* of those things to see a
> *state.State,
> > and I'm going to start treating new workers that violate layering this
> way
> > as deliberate sabotage attempts. Leads who have overseen the introduction
> > of those workers, sort it out.
> >
> >
> >
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150908/408c5106/attachment.html>