Shawn Walker wrote: > [snip] >>>>> >>>>> >>>>> beadm.py: You might consider using our misc.py bytes_to_str method >>>>> instead of rolling your own in __convert_size_of_be_to_string(self, >>>>> be_size). I'm guessing that what we have should be sufficient, or >>>>> can be >>>>> made to do what you need it to do. >>>> >>>> Good to know. I didn't wanted to depend on more code from IPS, >>>> since this would introduce risk if the misc.py bytes_to_str would >>>> be changed or renamed. What do you think? >>> >>> If it gets renamed by us, it's our responsibility to fix it. If it >>> gets changed, that's on purpose. Either way, using that function >>> will be good since it will ensure that the gui and cli represent >>> sizes of "things" the same way. >>> >> >> I disagree with this answer, at least in the long term. This is >> exactly how we got into this problem in the first, and why we're >> creating an API in the first place. Now, if we want to confer onto >> misc.py special API status such that every change made in that file >> has to be vetted against everything, then I'm fine with that answer. >> My impression is that misc is more or less a dumping ground for >> things we don't have better places for. Six months or a year from >> now, are we likely to remember that this one function of misc.py has >> been given special status? > > No, that is not how we got into this problem in the first place. We > got where we are today because the API wasn't broken up into re-usable > pieces so the GUI team had no choice but to copy sections of it to > advance their project. Actually, there are several ways we got into this situation. One is the copying of code. But, we've also broken the GUI by replacing imageplan.directories with imageplan.get_directories and adding a required argument to a function the gui was using (can't remember exactly which one at the moment, but if you need me to, I'll go dig it up). I suspect there were more as well, but those two came to mind immediately. > > And yes, I would expect anyone changing any functions in misc.py to > search the entire codebase (which the gui is now part of) to see how > their changes might impact other code. > > There is no such thing as "special status" in my mind for these > functions. They're part of our "library" of operations. Now, our > standard API may be the only thing we guarantee to work for clients > outside of our gate, but for everything in our gate, any changes we > make should be reflected across its entire contents. I disagree, or at least I think we're making or life more difficult and the code more brittle than it needs to be. I tend to believe that modular software is easier to develop and test than code which is tightly coupled. Further, the smaller the modules are, and the more well defined the interfaces are, the easier it is to test each module separately and to adequately test the interactions between the modules. It's true, the CLI, the GUI, and the back-end all now live in the same gate. I don't think that means that we can't try to treat them as separate modules. Honestly, if the only problem has been that the GUI's copied code, then let's just beef up the progress tracker so that it does what's needed. add in the extra calls to client.imageplan and client.image, and be done with it. I can stop working on this API and head back to search or the fun installing two packages which claim the same file problem. My impression, because the API was made such a high priority, was that we were trying to move towards a modular, long term design which would make it easier for other developers to build front-ends to our back-end without having to dive into the grungy details of our code. If that's not the case, if the API is really just a temporary solution we're putting in until we can beef up imageplan and image.py or until we get better practice at coordinating our changes with the GUI, then I'll changer my priorities appropriately. I don't mean that in a snarky way, but if I'm designing an API to last a few months to tide us over, then it's probably not worth putting all the extra functionality in or really thinking carefully about the design or what we're exposing to the world.
Thanks, Brock > >> If we think it's important for the GUI and the CLI to display byte >> information in the same pattern, then that becomes part of the >> conceptual API/standards. If the GUI makes calls into misc.py, then >> that function becomes part of the implementation API. Neither of >> these imply that the function has to move into api.py, but it does >> confer a status on that function that isn't given, generally, to most >> of our functions. > > I disagree. However, you're free to make it part of the API if you > think it needs to be. I don't think special status needs to be given > for code that lives in our gate. > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
