Brock Pytlik wrote: > 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. Another idea came to my mind while walking home :) So if the pkg.misc should be used, we could try to use this function and if this fail we could silently disable size column. I know that this is not an ideal situation, but we will still be able to use BE Management Dialog rather then breaking with ugly stack trace.
>> >> 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
