Brock Pytlik wrote: > Shawn Walker wrote: >> Michal Pryc wrote: >>> Brock Pytlik wrote: >>>> Michal Pryc wrote: >>>>> Hello, >>>>> I have made some changes to support BE Management: >>>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=3201 >>>>> >>>>> The webrev is at: >>>>> http://cr.opensolaris.org/~migi/10_09_be_management_3201_v1/ >>>> I know the interface to libbe has changed (or changes in 97). Please >>>> take a look at the change Tim Knitter put back (501:9467b61d5b40) >>>> and do >>>> something similar every place you use be.beList. We need this to be >>>> compatible both with the new code and the old code so we can >>>> continue to >>>> back-publish. >>>> >>>> beadm.py line 163 is where be.beList is being used. >>>> >>>> It's also probably worth your time to talk to the people writing libbe >>>> to find what changes they might have planned for their API, or to at >>>> least let them know that you're directly dependent on them. Ethan Quach >>>> is the person who've I've talked with about libbe before. >>>> >>>> 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. 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. > 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. -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
