slate wrote: > Kids egg is not working. I solved this problem by downloading kids > source. I made an egg with setup.py, and installed this on my computer.
FYI, the issue is that kid's setup.py actually imports kid at the beginning, and kid's initialization code imports ElementTree. This is broken, since until the setup actually runs to completion, there may not even *be* an ElementTree package installed. And if you *do* have ElementTree installed, it may need to extract a resource from that egg, which then causes the SandboxViolation. I do plan to make the SandboxViolation be ignored when it's pkg_resources doing the violating, but that won't fix the fundamental brokenness of a package trying to import its dependencies from within its setup script. :( By definition, when a setup script is running, the code is *not installed yet*. In general, then, it's an extremely bad idea to import code from your project inside your setup script. Some of the recent dependency problems with the TurboGears quickstart were indirectly caused by the exact same issue (i.e., importing TurboGears inside a setup script, when Turbogears was a requirement of the project, but not yet require()d by setup_requires). Unfortunately, because the author's machine already has everything set up the way they want it, they don't notice any problems from this kind of code. I wish there were some way to warn package authors about the issue. Maybe I should have setuptools output a warning when setup() is called, if any of the modules or packages that are listed for installation have already been imported from the source directory. That would help dispel the illusion that the setup will still work correctly when the package is distributed. Ideally, I suppose it should also check for any imports coming from dependencies listed in install_requires, or maybe just any non-setuptools, non-stdlib imports, except for non-distributed modules or packages in the setup directory. That does seem a bit draconian, though.
