← Back to team overview

launchpad-dev team mailing list archive

Re: Should the import fascist die or get some teeth back? (was Re: Notes about security and view code)

 

On Fri, Jul 31, 2009 at 8:32 AM, Gary Poster<gary.poster@xxxxxxxxxxxxx> wrote:
>
> On Jul 30, 2009, at 12:50 AM, Michael Hudson wrote:
>
>> Michael Hudson wrote:
>>>
>>> Gary Poster wrote:
>
> ...
>
>>>> - An import fascist controls what can be imported.  You may only import
>>>> code in a module's __all__.  This actually affects all code, not just
>>>> view code.
>>>
>>> I do wonder what the import fascist buys us these days.
>>>
>>> It used to, at least, prevent one from importing database code into
>>> non-database code, which would have been another way to punch through
>>> our security, and indeed I thought that was more of the point than the
>>> __all__ business.
>
> Actually, I had that impression as well, but as you say, it didn't seem to
> be doing that any more...
>
>>> It doesn't look like this got updated to prevent
>>> lp.foo.browser.bar importing from lp.baz.model.quux though, and I don't
>>> think we've missed it.
>>
>> That said, the use of the naked SourcePackage class at
>> branchlisting.py:1663 is at least a bit dodgy.  Maybe we should update
>> the facist...
>
> I've had similar thoughts--i.e., maybe the import fascist should die, or
> maybe it should be made more effective.  I do think it should be one or the
> other.
>

I agree wholeheartedly.

> What do others think?  Should we kill the import fascist?  Or try to make it
> better enforce the things we care about?  Or is it fine as is?
>

I think if we keep it, we certainly need to make it enforce the things
we care about, and (more importantly) make it stop warning us about
things we don't care about.

It'd be nice to get some kind of lint report for the lp.foo
inter-package dependency. It'd be pretty terrible if that caused
landings to fail.

I think it's also important that the rationales behind the
importfascist be easily discoverable, and that both importfascist &
rationales are kept up to date with how we actually think about the
structure of the Launchpad code base.

I guess this means that I lean mildly toward keeping it & fixing it. I
could be very easily persuaded to change my vote to removing it.

jml



References