Are there best practices on creating/using egg extras?
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
At 01:50 PM 7/20/2007 -0500, Dave Peterson wrote:
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?
Note that if you have code that imports from your extras, you can always include: pkg_resources.require("X[1]") right before the imports. Then, instead of an obscure import error, users will get an obscure DistributionNotFound error that at least tells them one of the packages they'll need to install. ;-)
Phillip J. Eby wrote:
At 01:50 PM 7/20/2007 -0500, Dave Peterson wrote:
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?
Note that if you have code that imports from your extras, you can always include:
pkg_resources.require("X[1]")
right before the imports. Then, instead of an obscure import error, users will get an obscure DistributionNotFound error that at least tells them one of the packages they'll need to install. ;-)
Right. Always better to have an obscure error that is more informative about how to solve it. :-) But someone still needs to know when to insert pkg_resources.require("X[1]") in their code. Which means knowing which symbols in X's API need a given extra. So I'm back at my original problem, no? -- Dave
participants (2)
-
Dave Peterson -
Phillip J. Eby