[Grok-dev] strategy for losing the zope.app packages

[Reinout van Rees]

On 12/10/09 11:03 PM, Martijn Faassen wrote:
> Reinout van Rees wrote:
> [snip]
>> For internal use I took your "importchecker" script and turned it into
>> z3c.dependencychecker.  It is now in zope's svn. (And on pypi).
> [snip]
>
> Cool!
>
> I am happy to see importchecker has such a long life. I recently used
> pyflakes (taking some buildout configuration, probably yours :) and I
> thought, ah, I guess this makes importchecker less useful, but it seems
> still useful enough.

For the real importchecking I normally use pyflakes.  Especially also 
for the other items it reports, though.

> I wonder whether z3c.dependencychecker (or some other tool?)) could be
> taught about moved dependencies.
>
> If my package A that imports from package B that in turn imports from
> package C, it might be I want to import from package C directly. Of
> course this is only a heuristic: in some cases package B imports from
> package C to establish a new API, for instance in its __init__.py
> (Grok's __init__.py is an example).
>
> Still, this information is very interesting, especially for Grok
> extensions which might be able to just rely on grokcore.* packages, and
> of course for packages that rely on the ZTK.
>
> Earlier this year Christian Theune tried to check for this kind of stuff
> by instrumenting the test runner to detect such imports, but he got stuck.
>
> Note that I'm talking about package dependencies (project dependencies,
> really), not module dependencies.

Well, once your setup.py dependencies are in tip-top shape after running 
z3c.dependencies, other tools can do their job.

The one I'm going to look at (probably friday) is at how the dependency 
graph tools do it. Do they display the setup.py dependencies? I think 
so, but I'm not sure.

So I'm gonna look at tl.eggdeps tomorrow, as that's the dependency graph 
thingy I'm currently using (with a small wrapper to have just one 
command to open up a png).


Martijn: now that I think about it: how would the package dependencies 
help with your idea? You still need to look at those packages to see 
what they provide.  The things that get moved are individual classes, 
not packages as a whole.

I *love* making tools like this :-)



Reinout

-- 
Reinout van Rees - reinout at vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
"Military engineers build missiles. Civil engineers build targets"