>> I think this will take both of us to tackle. My idea is to start
>> disabling parts of ipdoctest, or run the test suite on small parts of
>> the codebase to try to isolate where the problem is coming from.
>> After all the time I spent on this one, I think we should for now
> leave it, since we have an ugly but functional workaround. Given how
> little explicit coupling there is between the two things, I suspect
> that this will require making a specific branch (to be thrown away
> when done) where we start deleting *tests* until we find which one is
> causing this. I suspect that it's not the one that raises the error
> but something else up the chain instead.
Yes, let's take a break from this.
>> * For really public facing developer APIs, I will put in a
>> compatibility layer with deprecation warnings.
>> Big +1 to this. By the way, in the disentagling front, keep in mind
> my earlier comments about the biggest problems to fix being:
I will need some help identifying the main developer APIs that need to
be handled in this way. Although, I am hoping that as I dive in, it
will become obvious.
> - ipmaker/iplib: ipmaker is kind of a 'super __init__' mess that needs
> to disappear, folding it into iplib while making the lot be
> rational/comprehensible.
I might wait to do this until I am tacking the issue of removing the
various threading shells.
> - genutils
>> - making magics standalone
> I hope these pointers help you a bit.
Yep!
>> The only thing that will change in the actual code though will be
>> import statements and all of this will be tested. No API changes will
>> be combined with this reorganization work. This reorganization is
>> needed to help us really identify and isolate the things that need to
>> be refactored moving forward
>>>> But, because this work will move *everything* around, it will be
>> difficult to merge branches back in in an automatic way. By hand
>> though it might not be too bad to merge things.
>>>>> Part of that is communicating a plan for the breakage to everyone in
>>> advance, so that feedback can be provided by all affected before
>>> anything irreversible has happened.
>>>> Yes, I will absolutely ask for feedback about these plans before
>> starting. I am working on an IPEP (IPython Enhancement Proposal) that
>> describes my plans. More details to follow soon...
>>>>> Furthermore, I'd like to suggest that post 0.10 we hold a 'bug and
>>> test weeks' (2-4 max) to see if we could do an 0.11 release where we
>>> basically try to *only* fix existing tickets and add as many tests as
>>> we can, before starting to do major API breakage.
>>>> In theory this is a great idea. In practice this timescale will cause
>> problems with the work I need to do. I currently have funding that
>> ends May 1 to work on this and I need to get started immediately. It
>> is so rare to have dedicated time and $ for this, I don't want to
>> waste the opportunity. That is basically 4 weeks away. In reality, I
>> think I should soon just "go for it" and help people to do their
>> merges into my branch by hand.
>> No problem. Honestly we need this so badly, that it would be madness
> from my part to get in the way. So fire away :)
Cool.
> One suggestion: because LP only allows code reviews from logged in
> users/ team members, let's have the bulk of this design discussion on
> list rather than on LP. I also like better having this archived on
> our main mailing list for searching, etc. Once we get into actual
> code reviews for merging, we can leave that to happen on LP.
OK, that makes sense, I will try to keep the discussions here.
Cheers,
Brian
> Cheers,
>> f
>