Hello, I'm not sure if I've painted Enthought into a corner or not, but I can't figure out if there is a way to help users of a library, delivered as an egg, to know and/or maintain dependencies on extras declared in that egg. By which I mean that if my library, called X, declares extras 1, 2, and 3, and the source for X includes all the code that implements the features in extras 1, 2, and 3, and the extras document the external dependencies component X has to get those extras to work, how does someone importing from the API in X know whether their dependency on it should be 'X', 'X[1]', X[1,2]', etc. ? After all, all the API methods are already there even if they didn't install the extras. So far the only mechanisms I can see are (a) a manual one which depends on people (everyone using X!) knowing the internals of X such that they can tell that if they import symbols a, b, or c, then that means they need extra 1, etc., and (b) trial and error iteration driven by unit / integration tests.
Am I just misusing or misunderstanding extras here? BTW, what I'm trying to do is convert Enthought's old monolithic distribution of ETS into components that could be installed individually. The first step of this was to package each component as an egg; the second was to ensure that cross-component dependencies were put in place (simply declaring A requires B if code in component A imported a symbol from packages in component B); the third was to try to minimize these cross-component dependencies by minor refactoring and introduction of extras to represent non-core functionality; and the fourth is to ensure that cross-component dependencies properly include extras as needed. It's this last step that has got me thinking about this problem. I've been able to mostly automate the previous steps, or at least write tools to help me, but for this fourth step, I can't figure out how to do it consistently. It is quite possible that I've missed some best practice of when to create or use extras. Any advice would be greatly appreciated! -- Dave _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
